[opensuse-es] Posible estrategia de copia de seguridad
Veamos. Supongamos que hago copia del directorio "Documentos" en Blue Ray (archival quality), que es un medio de larga duración pero sólo escritura. Si un tiempo después quiero guardar lo que haya cambiado, sería suficiente fijarme en la fecha de modificación? E ignorar lo anterior. Hum... eso no incluiría directorios o ficheros antiguos movidos desde otro sitio, pues mantienen su fecha antigua. Tendría que comparar con un listado. Hay alguna herramienta de copia de seguridad en Linux (para DVD/BR) que cubra esa estrategia, es decir, que al menos liste todos los ficheros que no tengan copia en el backup? Hay una posibilidad, que es hacer un rsync a disco duro, y pasar a BR esa copia. La siguiente vez se hace otra copia con rsync (en otro directorio) con enlaces duros a los ficheros no cambiados. A BR se pasaría este nuevo directorio. Eso cubriría la idea de tener dos copias de seguridad, ¿no? Huh, no. El segundo directorio a todos los efectos excepto espacio en disco contiene una copia completa. La copia de BR tendría que detectar los ficheros con enlaces y obviarlos. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Hola,
Muchas herramientas de backups hacen esto.
Yo te puedo comentar sobre bacula.. puedes:
1 - realizar un backup Full a disco (no te recomiendo al blueray
directamente, pero igual es posible).
2 - realizar un trabajo de copy/move del backup al bluray.
3 - los siguientes backups, configuras como diferenciales/incrementales y listo.
Bacula guarda los HASH de los archivos en una BD, por esto no
necesitarías del bluray para revisar si esta o no modificado el
archivo.
Podrias crear un esquema en que realizas:
- un respaldo completo a cada 3 meses (de alli reenvia al bluray)
- diferenciales a cada domingo
- incrementales a diario.
Creo que seria todo.
salu2
On Wed, Jul 24, 2019 at 9:53 AM Carlos E. R.
Veamos.
Supongamos que hago copia del directorio "Documentos" en Blue Ray (archival quality), que es un medio de larga duración pero sólo escritura.
Si un tiempo después quiero guardar lo que haya cambiado, sería suficiente fijarme en la fecha de modificación? E ignorar lo anterior.
Hum... eso no incluiría directorios o ficheros antiguos movidos desde otro sitio, pues mantienen su fecha antigua. Tendría que comparar con un listado.
Hay alguna herramienta de copia de seguridad en Linux (para DVD/BR) que cubra esa estrategia, es decir, que al menos liste todos los ficheros que no tengan copia en el backup?
Hay una posibilidad, que es hacer un rsync a disco duro, y pasar a BR esa copia. La siguiente vez se hace otra copia con rsync (en otro directorio) con enlaces duros a los ficheros no cambiados. A BR se pasaría este nuevo directorio. Eso cubriría la idea de tener dos copias de seguridad, ¿no?
Huh, no. El segundo directorio a todos los efectos excepto espacio en disco contiene una copia completa. La copia de BR tendría que detectar los ficheros con enlaces y obviarlos.
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- -- Victor Hugo dos Santos http://www.vhsantos.net Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 24/07/2019 16.23, Victor Hugo dos Santos wrote:
Hola,
Muchas herramientas de backups hacen esto. Yo te puedo comentar sobre bacula.. puedes:
https://en.wikipedia.org/wiki/Bacula Considerations By default, Bacula's differential and incremental backups are based on system time stamps. Consequently, if you move files into an existing directory or move a whole directory into the backup FileSet after a full backup, those files may not be backed up by an incremental save because they may have old dates. Eso es precisamente el problema que dije podría pasar. You must explicitly update the date/time stamp on all moved files. Bacula versions starting with 3.0 or later support Accurate backup, which is an option that addresses this issue without requiring modification of the files timestamps. This feature should always be used if an accurate state of the filesystem is important. Which criteria should be applied is configurable, i.e. inode comparisons, modification times or md5/sha1 signatures. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
El mié., 24 jul. 2019 a las 19:41, Carlos E. R.
(
On 24/07/2019 16.23, Victor Hugo dos Santos wrote:
Hola,
Muchas herramientas de backups hacen esto. Yo te puedo comentar sobre bacula.. puedes:
https://en.wikipedia.org/wiki/Bacula
Considerations By default, Bacula's differential and incremental backups are based on system time stamps. Consequently, if you move files into an existing directory or move a whole directory into the backup FileSet after a full backup, those files may not be backed up by an incremental save because they may have old dates.
Eso es precisamente el problema que dije podría pasar.
You must explicitly update the date/time stamp on all moved files. Bacula versions starting with 3.0 or later support Accurate backup, which is an option that addresses this issue without requiring modification of the files timestamps. This feature should always be used if an accurate state of the filesystem is important. Which criteria should be applied is configurable, i.e. inode comparisons, modification times or md5/sha1 signatures.
Has de valorar otra cosa antes de tomar la decisión. Un backup no es más que una copia en el tiempo de un conjunto de datos - en tu caso un filesystem o una parte de él. Puedes hacer un backup full o un backup incemental (cambios sobre el último backup full) o un backup diferencial (cambios sobre el último backup de cualquier tipo)... y lo que decidas tiene implicaciones para la recuperación. Para recuperar un backup full solo necesitas un único full. Pero para recuperar la foto de tu filesystem desde un incremental o un diferencial necesitaras un full y: - todos los diferenciales desde dicho full. - el último incremental y el último full. (la verdad, siempre me lío entre incremental y diferencial... pero esos dos tipos de backup existen y has de tenerlo en cuenta para definir tu política de backup y el procedimiento tedioso de recuperación) Dado el coste de las unidades de blu-ray... y si no tienes unos requisitos de RPO muy exigentes... puedes hacer un backup full al mes - o a la semana si eres más exigente. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 24/07/2019 21.29, miguel gmail wrote:
El mié., 24 jul. 2019 a las 19:41, Carlos E. R. (<>) escribió:
On 24/07/2019 16.23, Victor Hugo dos Santos wrote:
Has de valorar otra cosa antes de tomar la decisión. Un backup no es más que una copia en el tiempo de un conjunto de datos - en tu caso un filesystem o una parte de él. Puedes hacer un backup full o un backup incemental (cambios sobre el último backup full) o un backup diferencial (cambios sobre el último backup de cualquier tipo)... y lo que decidas tiene implicaciones para la recuperación.
Para recuperar un backup full solo necesitas un único full. Pero para recuperar la foto de tu filesystem desde un incremental o un diferencial necesitaras un full y: - todos los diferenciales desde dicho full. - el último incremental y el último full.
Sí, conozco esa terminología.
(la verdad, siempre me lío entre incremental y diferencial... pero esos dos tipos de backup existen y has de tenerlo en cuenta para definir tu política de backup y el procedimiento tedioso de recuperación)
Dado el coste de las unidades de blu-ray... y si no tienes unos requisitos de RPO muy exigentes... puedes hacer un backup full al mes - o a la semana si eres más exigente.
No, para backups frecuentes usaré el disco duro que está en camino. Estoy pensando en guardar en blueray cosas que no van a cambiar en la vida, como fotos o vídeos. Pueden haber nuevas fotos, pero las que existen no cambian. Se trata de algo que lleve la cuenta de qué cosa está guardado donde, pero básicamente para restaurar es restaurar todos los discos BR. Si algo se ha modificado, pues se copia dos veces y ya está. Para documentos pues ya hace falta tener en cuenta modificados/borrados. Antes había programas de backup que le decías que guardar y luego ya era sólo cuestión de cambiar el flopy cuando te lo pedía, sin pensar. Se encargaba de todo. Si hubiera alguno que lo hiciera con DVDs o BR... Y para recuperar pues podías mirar el catálogo y recuperar un fichero o todo. Años 80..90. PCtools backup. De pago. En MSDos. Y rapidísimo, no daba tiempo a pegar las etiquetas de los flopies y escribirlas. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Hola,
vale, es que habia entendido otra cosa (mi problema de lectura) !!!
pero igual ya miraste que la opción de accurate resuelve el problema
que describes !!!
salu2
On Wed, Jul 24, 2019 at 1:41 PM Carlos E. R.
On 24/07/2019 16.23, Victor Hugo dos Santos wrote:
Hola,
Muchas herramientas de backups hacen esto. Yo te puedo comentar sobre bacula.. puedes:
https://en.wikipedia.org/wiki/Bacula
Considerations By default, Bacula's differential and incremental backups are based on system time stamps. Consequently, if you move files into an existing directory or move a whole directory into the backup FileSet after a full backup, those files may not be backed up by an incremental save because they may have old dates.
Eso es precisamente el problema que dije podría pasar.
You must explicitly update the date/time stamp on all moved files. Bacula versions starting with 3.0 or later support Accurate backup, which is an option that addresses this issue without requiring modification of the files timestamps. This feature should always be used if an accurate state of the filesystem is important. Which criteria should be applied is configurable, i.e. inode comparisons, modification times or md5/sha1 signatures.
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- -- Victor Hugo dos Santos http://www.vhsantos.net Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (3)
-
Carlos E. R.
-
miguel gmail
-
Victor Hugo dos Santos