Restic: Eliminar archivos de una instantánea existente

Creado en 15 nov. 2014  ·  57Comentarios  ·  Fuente: restic/restic

En casos de copia de seguridad accidental de, por ejemplo, archivos demasiado grandes, me gustaría poder eliminar archivos o directorios específicos (incluida la recursividad) de las instantáneas existentes

user interface feature suggestion

Comentario más útil

Entonces, gracias a todos por sus comentarios, tenemos un camino claro a seguir: implementar un comando que permita eliminar archivos de una instantánea existente. El nombre del comando se decidirá cuando lleguemos allí. Podemos revisar los otros casos de uso cuando surja la necesidad.

No creo que necesitemos más discusión aquí, ¡gracias por participar!

Todos 57 comentarios

Eso estaría muy bien.

También permitiría eliminar datos confidenciales que se incluyeron sin saberlo.

¡Esto sería una gran característica!

¿Algún comentario de los desarrolladores sobre esta idea? Sería muy bueno. Por ejemplo, acabo de descubrir que un programa que construyo a partir de git checkouts ha estado creando enormes binarios (casi 100 MB), y estos han sido respaldados en mis copias de seguridad de Restic innecesariamente. No he estado usando Restic durante mucho tiempo, ya que todavía estoy en una fase de prueba, por lo que no es un problema eliminar las instantáneas antiguas en cuestión. Pero este problema puede suceder con bastante facilidad y sería bueno tener soluciones a largo plazo, además de olvidar cada instantánea.

Supongo que sería posible escribir un script para restaurar cada instantánea, eliminar archivos no deseados y volver a hacer una copia de seguridad de la instantánea configurando la fecha manualmente, pero obviamente eso llevaría mucho tiempo. Sería genial si Restic pudiera hacer esto de forma nativa.

Gracias.

Creo que hay varios casos de uso válidos para esto. Parece una característica realmente buena. Probablemente lo usaría yo mismo en algún momento.

Probablemente no cambie realmente el esfuerzo de implementación, pero desde un punto de vista de UX, esto podría hacerse con un perfil bastante bajo extendiendo el comando backup lugar de agregar un comando completamente nuevo:

restic backup [flags] FILE/DIR/SNAPSHOT [FILE/DIR/SNAPSHOT] ...

Entonces, en lugar de ofrecer un comando que modifique las instantáneas, esto permitiría hacer una nueva copia de seguridad basada en una ID de instantánea existente. Eliminar un archivo se lograría con reglas de exclusión.
Toda la documentación sobre restic backup básicamente podría "reutilizarse" (es decir, no sería necesario agregar casi nada para esta nueva característica).

@dnnr Ver https://github.com/restic/restic/issues/1550#issuecomment -358536554

Sin embargo, no te sigo aquí. Eliminar datos de instantáneas antiguas es definitivamente una operación distinta y debe tener su propio comando. Algo como:

restic purge --snapshots abcd1234 deadbeef --paths /path/to/file1 /path/to/file2

Y --snapshots probablemente debería aceptar una palabra clave all para operar en todas las instantáneas (o todas las instantáneas con el --tag especificado). Y el comando probablemente debería requerir confirmación escribiendo yes .

También sería bueno que tuviera una opción --patterns , que eliminaría las rutas que coincidan con los patrones dados.

purge es una posibilidad para el nombre del comando. erase también puede ser una buena opción, así como delete . Independientemente de lo que se elija, debe dejar en claro que la operación elimina datos de forma permanente . Este es un software de respaldo del que estamos hablando, y cualquier operación peligrosa debe ser distinta, explícita y requerir confirmación.

Bueno, dejé de lado el paso en el que eliminarías la instantánea de origen después (usando forget , luego tal vez prune ), porque pensé que era obvio.

En mi opinión, hacerlo así mantendría el conjunto de comandos más ortogonal en comparación con agregar un nuevo comando que se superpone con la funcionalidad de los comandos existentes. En este momento, hay backup , forget y prune y todos hacen cosas completamente separadas. Agregar un purge como lo describe, cambia eso. Mi sugerencia no lo hace.

dado que estamos proponiendo operaciones de un archivo, sería bueno poder cambiar el nombre.

Estoy de acuerdo con @alphapapa en que debería haber un comando distinto para este tipo de operación. Puede ser purge , eso no es un mal nombre, entonces nuevamente podría haber otras operaciones similares en el futuro, por ejemplo, @alvarolm ya sugirió poder cambiar el nombre de los archivos.

Por esa razón, creo que quizás agregar un comando rewrite es la mejor alternativa en este caso, y hacer que ese comando tenga, por ejemplo, las opciones --purge y --rename , asumiendo que este último es relevante para implementar. Entonces, los comandos finales serían, por ejemplo, restic -r foo rewrite --purge snap1,snap2 path1 path2 ... y restic -r foo rewrite --rename snap1,snap2 pathFrom pathTo .

Dicho esto, no estoy del todo seguro de que el cambio de nombre sea algo razonable de implementar; va muy lejos de lo que trata un programa de respaldo. Pero claro, por qué no.

No creo que sea prudente que las cosas de purga sean parte del comando de respaldo. Desde una perspectiva, podría argumentar que está bien: está realizando una operación en su copia de seguridad. Pero con ese fundamento, las acciones de podar, desbloquear y olvidar también deberían ser parte del comando de respaldo, ya que también se trata de mantener cosas en su respaldo. No creo que tenga sentido, así que creo que debería ser una operación / comando separado, por ejemplo, rewrite o purge .

@dnnr

Bueno, dejé de lado el paso en el que eliminarías la instantánea de origen después (usando olvidar, luego tal vez podar), porque pensé que era obvio.

Definitivamente no es obvio. También es mejor si Restic maneja eso para el usuario, en lugar de que el usuario tenga que realizar un seguimiento de las ID de instantáneas que han cambiado y deben olvidarse, lo que sería una gran carga si el usuario estuviera reescribiendo todas las instantáneas en el repositorio.

En mi opinión, hacerlo así mantendría el conjunto de comandos más ortogonal en comparación con agregar un nuevo comando que se superpone con la funcionalidad de los comandos existentes.

No entiendo lo que quieres decir. Ocurre justo lo contrario. Este comando de purgar / eliminar / reescribir propuesto no se superpone con backup en absoluto: elimina datos de las instantáneas existentes . Que es ortogonal a los comandos existentes.

En este momento, hay respaldo, olvido y poda y todos hacen cosas completamente separadas. Agregar una purga como la describe, cambia eso. Mi sugerencia no lo hace.

Una vez más, no tengo idea de lo que estás pensando aquí. purge es completamente independiente de la copia de seguridad, el olvido y la poda:

  • backup : Crea una nueva instantánea de las rutas dadas.
  • forget : Elimina las instantáneas existentes.
  • prune : Garbage-recolecta blobs no utilizados de instantáneas olvidadas.
  • purge / rewrite / lo que sea: elimina archivos de las instantáneas existentes.

Está proponiendo hacer que el comando backup opere en dos modos, uno de los cuales respalda los datos y el otro los eliminaría.

@rawtaz Sí, rewrite es una buena sugerencia, porque literalmente reescribe las instantáneas existentes. Sugeriría una interfaz de usuario como:

restic --repo REPO rewrite --snapshots abcd1234 deadbeef --delete /path/to/file1 "*.unwanted-file-extension-glob"

Recomiendo no usar comas como separadores, porque hace que la construcción de líneas de comando en scripts sea mucho más complicada.

copia de seguridad: crea una nueva instantánea de las rutas dadas.

Bueno, en cierto sentido, modificar el contenido de una instantánea es crear una nueva instantánea (porque no es la misma instantánea que antes). Piense en git commit --amend , que crea una nueva confirmación basada en una confirmación existente. La analogía es bastante adecuada, ya que este boleto parece avanzar rápidamente hacia la reinvención de Git.

Usted propone hacer que el comando de respaldo opere en dos modos, uno de los cuales respalda los datos y el otro los eliminaría.

Yo no dije eso. ¿Por qué lo haría? Hay forget y prune , que están perfectamente bien para eliminar cosas.

Bueno, en cierto sentido, modificar el contenido de una instantánea es crear una nueva instantánea (porque no es la misma instantánea que antes). Piense en git commit --amend, que crea una nueva confirmación basada en una confirmación existente. La analogía es bastante adecuada, ya que este boleto parece avanzar rápidamente hacia la reinvención de Git.

Tienes razón. Pero al mismo tiempo, Restic no es un git y no está diseñado para requerir conocimientos de direccionamiento basado en contenido para funcionar. Independientemente de cómo funcione bajo el capó, creo que, para los usuarios, el comando que estamos proponiendo debe considerarse para modificar una instantánea existente, no crear una nueva, por lo tanto, debe ser un comando distinto.

Yo no dije eso. ¿Por qué lo haría?

Bueno, dijiste:

desde el punto de vista de UX, esto podría hacerse con un perfil bastante bajo extendiendo el comando de respaldo en lugar de agregar un comando completamente nuevo

Quizás deberías explicarlo con más detalle.

Hay olvido y poda, que están perfectamente bien para quitar cosas.

Seamos específicos. forget elimina las instantáneas y prune elimina las manchas . Estamos proponiendo un comando para eliminar archivos dentro de instantáneas . Debería ser un comando distinto.

Me gustaría agregar mi opinión:

Creo que tener una forma de modificar las instantáneas en el repositorio es valioso, según los comentarios de cuántas personas les gustaría tener algo como esto.

El comando debe ser independiente del comando backup , no solo por razones de ortogonalidad (que es bastante similar a Go), sino también por consideración práctica: el comando backup ya es lo suficientemente complejo, por lo que Me gustaría separar el otro comando de él.

No me gusta el nombre purge , debido a la similitud con prune . ¿Qué pasa con change ? Luego tenemos restic backup , restic restore y restic change .

Para las operaciones admitidas del comando, he visto solicitudes para:

  • Eliminar archivos, por ejemplo, --delete
  • Cambiar el nombre de los archivos, por ejemplo, --rename

El primero es exactamente de lo que trata este problema (originalmente), pero ¿existen realmente casos de uso para cambiar el nombre de los archivos?

Creo que change suena más como sacar algo y poner algo, en lugar de modificar el contenido de algo.

Imagina que el repositorio / copia de seguridad / instantánea es un depósito. El cambio es más como cambiar el balde por otra cosa, o sacar algo de él y poner otra cosa dentro, en lugar de recoger algo en el balde, modificarlo un poco y volver a colocarlo.

Quizás alguna persona nativa de inglés / americano sepa cuál es más apropiado :) Creo que se reduce a la lingüística.

Hm, modify entonces?

modify es definitivamente mejor que change . Entonces, o rewrite o modify de lo que se ha propuesto hasta ahora. Curioso lo que piensan los demás :)

Si solo se trata de eliminar archivos, ¿tendría sentido mejorar el comando forget para que funcione con instantáneas y archivos? ¿O sería demasiado complejo?

Si esta nueva función se trata de eliminar y cambiar el nombre (o algo más), votaría por modify .

Gracias por tu aporte @dimejo 👍

Creo que cuando estás cambiando el nombre y / o borrando, no estás forget ting (al menos no en el primer caso).

En mi humilde opinión, "reescribir" transmite mejor el significado.

El comando forget también es muy complejo, no agregaremos nada si podemos evitarlo;)

Si va a ser un comando separado, llamarlo modify sería mi favorito (también me gustaría modify-snapshot , aunque es bastante largo). También es lo suficientemente genérico como para ser un lugar apropiado para todo tipo de operaciones de modificación de archivos (cambiar el nombre, tal vez incluso agregar). Sin embargo, sigo pensando que todo lo que vaya más allá de la eliminación de archivos huele mucho a fluencia de funciones.

Por cierto, creo que restic se beneficiaría de las categorías de comando, similar a lo que tiene Git con sus comandos de plomería. En este momento, restic -h enumera todos los comandos en orden léxico, mezclando comandos de bajo nivel (por ejemplo, cat , list , que los usuarios "normales" nunca necesitarán) con los comandos primarios de alto nivel.

También puede considerar update .

+1 por rewrite , tiene un bonito anillo orwelliano. :-)

alter
discard
evict
expel
expunge
extrude
oust
...
nuke ? 😄

Me gustaría proponer un nuevo comando edit . Según todos los comentarios sobre este problema, me parece que podríamos terminar con múltiples acciones para edit una o varias instantáneas.

Por el momento, podría ser algo como:

$ restic edit 40dc1520 remove dir/file

En el futuro, podríamos implementar la eliminación de un archivo de varias instantáneas (lista de entrada de ID de instantánea o rango de fechas).

Otros comandos en el contexto de edición pueden ser

  • rename para cambiar el nombre de archivos y carpetas
  • move para corregir las estructuras de archivos / directorios que pueden haber cambiado

Creo que es importante que permitamos que estas acciones se ejecuten en una o varias instantáneas (por ID o posiblemente varias fechas o un rango).

Todavía no estoy seguro de cuánto restic debería poder hacer con los datos respaldados. Quiero decir, está destinado a hacer una copia de seguridad de los datos para preservar cómo se veían las cosas en un momento determinado. No está destinado a ser un NAS.

Especialmente no veo la validez en el caso de uso de cambiar el nombre y eliminar archivos. Quiero decir, ¿por qué cambiarías archivos en tu disco local y luego jugarías con tus copias de seguridad para mantener su árbol de archivos sincronizado con tus datos actuales? No tiene sentido para mi. ¿Puede dar más detalles sobre ese caso de uso?

@rawtaz
Mis pensamientos (casi) exactamente.

Yo diría que la validez de eliminar archivos radica en el escenario en el que descubre un error en sus reglas de exclusión después de haber realizado copias de seguridad con esas reglas. Por lo tanto, la eliminación de archivos sirve básicamente como la aplicación retroactiva de las reglas de exclusión. Parece que, independientemente de la controversia en este hilo, todos están de acuerdo en ese caso de uso en particular.

Con respecto a las operaciones más allá de eso (es decir, cambiar el nombre, agregar), comparto sus dudas. Es una característica lenta y no está en el alcance de una herramienta de respaldo, en mi humilde opinión.

Estoy de acuerdo: eliminar archivos de las instantáneas es importante, ya que es muy fácil hacer una copia de seguridad accidental de archivos que uno no tenía la intención de hacer. Esto suele ser necesario tanto por motivos de seguridad como por motivos de uso del disco. Tener esta función podría significar la diferencia entre poder conservar los datos de respaldo antiguos o tener que "tirar al bebé con el agua de la bañera".

Pero cambiar el nombre o mover archivos dentro de una instantánea probablemente no sea una buena idea. Para ser franco, nunca he oído hablar de un software de respaldo que pueda hacer esto, y parece una característica extraña. Si un usuario lo necesitara absolutamente, podría implementarse fuera de Restic restaurando la instantánea, reorganizando los archivos y haciendo una copia de seguridad nuevamente con la fecha establecida explícitamente (aunque esto podría volverse más complicado en el futuro cuando Restic comience a usar rutas absolutas) .

Por supuesto, la función de eliminar rutas de instantáneas también podría implementarse de esta manera, pero como parece mucho más probable que sea necesaria, creo que es razonable que se incluya en Restic.

Entonces, gracias a todos por sus comentarios, tenemos un camino claro a seguir: implementar un comando que permita eliminar archivos de una instantánea existente. El nombre del comando se decidirá cuando lleguemos allí. Podemos revisar los otros casos de uso cuando surja la necesidad.

No creo que necesitemos más discusión aquí, ¡gracias por participar!

Sugerencia para el nombre del comando: restic purge .

Espero con ansias esta función. Gracias

@ fd0
¿Alguna actualización sobre esta función? Me encantaría usarlo :)
Estamos usando restic en un entorno gubernamental y para ellos es necesario eliminar un solo archivo de una copia de seguridad. ¡Podríamos financiar parte del trabajo si fuera necesario!

¡Yo también espero con ansias esto! Propongo usar algo como la estructura base para restic find .

restic purge [flags] PATTERN

Donde podría limitar el purge a host (-H) snapshots (-s) or paths (--path)

Entonces tal vez un restic prune luego haría la eliminación real

Esto sería muy útil cuando un archivo imprevisto se respalda por error (un video grande en una carpeta de documentos o tal vez un archivo confidencial) En este momento, ejecuto restic find luego elimino todas las instantáneas que contienen el archivo ... . Esto es menos que deseable si el archivo está lejos en el repositorio (en el tiempo)

Gracias !

Sin actualización, lo siento. Recibirás una notificación suscribiéndote a este problema cuando suceda algo.

Parece que la mayoría de la gente quiere poder clone los metadatos de una copia de seguridad, pero excluir los archivos ofensivos, sin tener que restaurarlos todos en una ubicación nueva. La idea de clonar una copia de seguridad copiaría metadatos con la capacidad de eliminar ciertos indicadores.

¿Es este el caso de uso?

  • restic backup --exclude <something> --clone <original backup id> [new feature]
  • restic forget <original backup id>
  • restic prune

rewrite y modify podrían ser macros del proceso anterior.

Para mí, eso sería suficiente @nullcake

No está mal, @nullcake.

Sin embargo, según mi experiencia pasada, generalmente detectaba que hacía copias de seguridad de un montón de cosas sin valor solo días o semanas después. Cuando tenga algo de tiempo para investigar. Lo que esto significa es que para el momento en que entiendo que necesito algo específico, excepto, probablemente haya una docena o más de copias de seguridad afectadas.

Por supuesto, incluso si se implementa algún tipo de limpieza basada en una única copia de seguridad, como sugiere, sería un gran paso adelante. Nosotros, por supuesto, sabemos cómo escribir un guión. ;)

Entonces, pulgares arriba. :)

Si bien esta es una idea interesante, me temo que el comando backup es demasiado complejo, y agregar otra "fuente" para una copia de seguridad lo complicará aún más. Además, esta función solo operaría en datos que ya están en el repositorio (solo en metadatos, para ser precisos). Un comando separado (por ejemplo, purge o menos) podría encapsular la funcionalidad muy bien.

CrashPlan tuvo un comportamiento interesante que cuando se excluye un archivo, se purga de todas las instantáneas existentes. Eso podría ser algo a considerar.

Esto sería una gran característica. ¿Ha sido agregado?

No.

@ fd0, ¿ ha habido algún progreso en esto? Acabo de descubrir que no estaba excluyendo cachés como pensaba y me encantaría eliminarlos.

Otra sugerencia más para un nombre de comando: scrub (aunque también estoy bien con purge , la bandera --rename me parecería extraña). Mis pensamientos:

restic scrub [--dry-run] [--replace=<clean|prune>] [--diff] [--all | snapshot-ID...]

Donde --replace=clean elimina cualquier instantánea modificada, prune limpia y ejecuta prune después. --diff muestra una diferencia para cualquier instantánea modificada. --dry-run evita realizar cambios en el repositorio.

También son válidas todas las banderas --exclude de restic backup . Supongo que --host y --time también tienen sentido (cada uno reemplaza los valores de la instantánea preexistente); --tag edición de restic tag .

¿Algún desarrollador tiene orientación sobre cómo se podría implementar? Me parece (de una mirada superficial) que la mayor parte del código puede ir en un archivo cmd_scrub.go ; tal vez solo sean necesarias algunas adiciones de API a la biblioteca interna, ya que parecen ser principalmente operaciones de índice, pero tal vez eso sea ingenuo. ¿Alguna dificultad estimada (supongo que las pruebas serán la mayor parte en cualquier caso)?

ya que se trata de un problema muy antiguo ... ¿hay alguna posibilidad de obtener esta función?

Para todo lo que monitorea esto en busca de actualizaciones y lo recibe de Google, no hay necesidad de esperar a que este problema nunca llegue a buen término, solo use duplicati mientras tanto, tiene soporte de primera clase para eliminar archivos posteriores a hechos de instantáneas.

Para todo lo que monitorea esto en busca de actualizaciones y lo recibe de Google, no hay necesidad de esperar a que este problema nunca llegue a buen término, solo use duplicati mientras tanto, tiene soporte de primera clase para eliminar archivos posteriores a hechos de instantáneas.

He estado usando restic durante aproximadamente un año y dejé de esperar a que se implementen las funciones. No quiero decir que todo deba agregarse a restic, pero hay cosas básicas que deberían estar allí. Estoy considerando alejarme de Restic: el repositorio es muy frágil y puede romperse con mucha facilidad.

Ayer eliminé una instantánea porque incluía archivos que no deberían haber estado en la copia de seguridad (olvidé agregar una exclusión). Desde entonces tengo errores en mi repositorio y aún no he podido repararlo. No debería tener que eliminar instantáneas completas porque algunos archivos se incluyeron por error.

@MorgothSauron Por lo general, solo

Deseo agradecer a todos por sus aportes sobre este asunto. Como hemos visto, muchas personas han querido en particular la posibilidad de eliminar archivos de una instantánea. Supongo que todos cometemos errores de vez en cuando al retroceder;)

En este momento, el tiempo disponible del desarrollador y del mantenedor es necesario en otras partes de restic, por lo que no preveo que este problema se implemente en un futuro previsible. También voy a lanzar un nuevo servidor de descanso tan pronto como pueda, y luego comenzaré a buscar otros problemas.

Dicho esto, si alguien hace un PR sólido que está escrito de manera agradable y clara, bien probado y libre de errores, y producido en coordinación con los mantenedores, definitivamente se considerará su inclusión. Este problema específico es uno en el que @ fd0 ya ha dado su bendición en la dirección, por lo que el enfoque puede estar principalmente en producir una implementación sólida (que sabemos que no dañará los repositorios) en lugar de "deberíamos agregar esta función", lo cual es bueno .

Dicho RP debe ser básico y actuar como un punto de partida sobre el que, si es necesario, se puede construir. Un ejemplo de lo que quiero decir con eso es que debería para empezar:

  • Solo sea un comando nuevo (por ejemplo, rewrite ya que es el más votado en este número).
  • Tome una lista de instantáneas como sus argumentos principales (incluido el soporte para all ), por ejemplo, all o 098db9d5 o 098db9d5 af92db33 .
  • Tome una lista de uno o más --exclude <pattern> para enumerar las rutas que deben excluirse / eliminarse de la instantánea (en otras palabras, aquí está el --exclude que faltaba al realizar la copia de seguridad), por ejemplo, --exclude="*.o" , --exclude=*.unwanted , --exclude="*.o" --exclude=*.unwanted --exclude=.DS_Store .

El fundamento aquí es obtener un comienzo mínimo como prueba de concepto y producto mínimo viable. Una vez probado, podemos ajustarlo según sea necesario, por ejemplo, agregando los otros --exclude-* argumentos del comando backup . Si hacemos un comando rewrite como este, tendrá prácticamente la misma interfaz que el comando backup que está destinado a "corregir":

~restic -r / some / repo rewrite all --exclude = " .o" --exclude = .unwanted --exclude = .DS_Storerestic -r / some / repo rewrite 098db9d5 af92db33 --exclude = " .o" --exclude = .unwanted --exclude = .DS_Store~

En una nota relacionada, quizás el trabajo realizado por @middelink en https://github.com/restic/restic/issues/323 podría usarse como inspiración o base para la implementación, ya que hace algún procesamiento de instantáneas existentes. Voy a ver si podemos ponernos en marcha con este demasiado pronto.

@rawtaz

¡Gracias por los atentos comentarios!

Hola.

Agregué el borrador de implementación rewrite cerca del comentario de @rawtaz

Funciona aquí con repositorio de prueba, pasa restic check --read-data sin errores, pero no lo he probado mucho. Por lo tanto, sugiero encarecidamente no usarlo con datos importantes.

He intentado que la sintaxis se acerque mucho al comando backup . Entonces --exclude , --iexclude y --exclude-file son compatibles (pero no probados). Idealmente, también quiero ver la opción --exclude-if-present (el flujo de trabajo ideal para mí es algo como 'oops, no es necesario hacer una copia de seguridad, agregar CACHEDIR.TAG y restic rewrite '). Pero es bastante complejo porque, en tal caso, necesitaremos rewrite en el mismo host donde se realizó la copia de seguridad y acceder al sistema de archivos para recopilar estos archivos (más toneladas de magia con rutas relativas). Así que ahora mismo no ...

Además, no me gusta la idea de reemplazar las instantáneas de forma predeterminada, por lo que actualmente el comportamiento predeterminado es simplemente crear una nueva instantánea con la etiqueta rewrite . Pero también es posible reemplazar con --inplace arg.

Cualquier comentario será muy apreciado.

Oye Dmitry,

Gracias por esta implementación, ¡gran trabajo!

Hasta ahora, funciona perfectamente en Linux con un pequeño repositorio de prueba de 600 archivos + varias instantáneas de prueba. La restauración funciona y muestra las carpetas correctamente excluidas. Haré pruebas más intensivas en un repositorio real "clonado" con muchos GB de datos con más de 100 instantáneas. También intentaré repositorios de Windows.

Una propuesta: tener la opción de especificar una etiqueta para las instantáneas que contenían las exclusiones en un pase de reescritura. (manteniendo la etiqueta " rewrite " en las instantáneas recién creadas).

restic rewrite --add-tag mytag -i thisfileshouldberemoved.txt all

Esto ayudaría a identificar aquellas instantáneas que aún contienen "_este archivodebería eliminarse.txt_". Por otro lado, el --inplace más directo funciona como se esperaba.

De nuevo muy buen trabajo.

@NovacomExperts Sí, mi motivación inicial fue mantener 'la edición del historial lo más segura posible. Es muy fácil excluir algo importante con --exclude * y casi no hay forma de recuperarse de esto (con la copia de seguridad es solo cuestión de comenzar una nueva copia de seguridad nuevamente). Algo como --dry-run pero con la capacidad de obtener una instantánea real y eliminar explícitamente la instantánea de origen después de verificar que esté bien.

Estoy totalmente de acuerdo en que actualmente esto no se logra por completo. Es fácil 'observar' nuevas instantáneas, pero demasiado difícil eliminar una antigua. Además, no me gusta el nombre de la instantánea rewrite codificado. Tal vez sea mejor tener --inplace por defecto y ---keep-source-tagged before-rewrite --tag-destination after-rewrite o algo como esto. ( --add-tag es un poco confuso, ya sea una instantánea antigua o nueva).

En cualquier caso, esperaré los comentarios de los mantenedores. No quiero perder mucho tiempo si se mueve en la dirección equivocada.

PD. Mi repositorio restic principal es de alrededor de ~ 2 TB ahora. Lo probaré más tarde después de hacer una instantánea de LVM.

@dionorgua Tu motivación inicial es totalmente correcta. Daré mi voto para mantenerlo así, con la opción "peligrosa" --inplace más lejos posible del usuario (definitivamente no por defecto). Preferiría un error de argumento faltante en --keep-source-tagged / --tag-destination que en --inplace por defecto.

Pero estoy de acuerdo, esperemos comentarios sobre esto.

Ayer, olvidé el repositorio de prueba clonado (65 GB) dentro de una carpeta de la que Restic realizó una copia de seguridad durante la noche. Podría tener la instantánea de ayer de forget pero fui "todo adentro" y probé su implementación. Después de forget + prune , eliminé con éxito los 65 GB de un repositorio de 400 GB. Todo bien, no se encontró ningún error.

Pruebo más intensamente con datos que abarcan varias instantáneas.

Salud

Reemplacé esa solicitud de extracción incorrecta # 2720 con una nueva porque la anterior se creó a partir de la rama maestra. Acabo de agregar una verificación de error faltante. Perdón por el ruido extra

Hm, modify entonces?

Muy tarde para esto, pero _rectify_ es mi sugerencia para el comando delete-specific-file-from-backup.

2731 es emocionante, ¡muchas gracias!

Muy tarde para esto, pero rectificar es mi sugerencia para el comando delete-specific-file-from-backup.

Tengo que decir que no es un gran nombre para eso. Rectificar implica que hay algo mal que necesita ser corregido / rectificado. Si bien esto puede ser cierto en uno de los casos de uso, no siempre es así. Es posible que un usuario desee simplemente eliminar algunos datos de las instantáneas existentes para liberar espacio para todo lo que sabemos, mientras conserva el resto de la instantánea. Creo que la redacción tiene que ser más neutral que rectificativa.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

e2b picture e2b  ·  4Comentarios

fd0 picture fd0  ·  4Comentarios

christian-vent picture christian-vent  ·  3Comentarios

TheLastProject picture TheLastProject  ·  3Comentarios

reallinfo picture reallinfo  ·  4Comentarios