De acuerdo con esto , puede usar la variable de entorno RESTIC_PASSWORD para especificar la contraseña.

Como ya dijo @pvgoran , puede usar la variable de entorno RESTIC_PASSWORD . Esto está documentado en el manual aquí http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository. Si tiene una idea sobre cómo documentar esto mejor, cree una solicitud de extracción.

También existe el problema # 278, que trata de leer la contraseña de un archivo.

Voy a cerrar este tema porque no hay nada que debamos hacer ahora. Si no está de acuerdo, deje un comentario.

Ay, y pensé que había leído esa sección hasta ...

¿Quizás darle a ese párrafo su propio título o subtítulo? Los primeros cuatro párrafos de esa sección cubren todo sobre la inicialización de un repositorio. La automatización de copias de seguridad realmente no encaja en eso.

Gracias @pvgoran por la respuesta rápida, por cierto. :sonreír:

Solo una breve pregunta de seguimiento sobre esto. Si una copia de seguridad no finaliza cuando cron se ejecuta restic nuevamente, ¿qué pasará?

En este caso, restic iniciará una segunda copia de seguridad (paralela), que utiliza datos ya cargados por la primera copia de seguridad (aún en ejecución). Supongo que ambas copias de seguridad terminarán casi al mismo tiempo. Habrá algo de duplicación de datos, que se limpia cuando se ejecuta el comando prune la próxima vez. Sin embargo, no causará daños ni pérdida de datos. El formato del repositorio está diseñado de manera que permite la carga paralela de datos.

Este es un caso interesante en el que no he pensado todavía. ¿Cree que necesitamos un código para verificar si la misma copia de seguridad ya se está ejecutando en el mismo host y salir en este caso?

@ fd0 Posiblemente, sí. Solo para la misma copia de seguridad. O, una forma limpia de realizar copias de seguridad automatizadas: algunas instrucciones servirán, tal vez "copia de seguridad restic", luego "desbloqueo restic" y luego "poda restic", por ejemplo. Pero no tener que preocuparse por esos comandos adicionales sería bueno.

restic backup seguido de restic forget y restic prune es el flujo de trabajo habitual, y eso lo limpia. Agregaré otro problema de todos modos, para que podamos rastrear esta idea.

¡Genial, gracias! Por ahora usaré ese flujo.

Otra opción aquí que podría ayudar es un parámetro de tiempo de espera. Si sabe que su trabajo cron programa una copia de seguridad cada X horas, puede pasar un tiempo de espera a restic para que termine antes de que comience la siguiente. También sería útil para otras cosas. (esto puede que ya exista, soy nuevo en restic)

Detectar que restic ya se está ejecutando suena complicado y no sé cómo se haría con precisión y limpieza desde dentro de restic. Especialmente porque podría tener diferentes copias de seguridad resticidas ejecutándose al mismo tiempo, lo que no debería contar.

Tal vez un script de inicio que sea similar a muchos de los otros scripts de inicio de Linux que toma el PID de restic cuando se inicia y lo guarda en un archivo tmp y luego lo elimina cuando restic finaliza. Cada vez que se ejecuta la secuencia de comandos, comprobará el archivo. Necesitaría un archivo tmp diferente para cada copia de seguridad programada única.

Desafortunadamente, cualquier medio de detectar una instancia restic en ejecución fallaría en TODOS los backends (SFTP, REST, S3 ...) excepto en el local.

@zcalusic podríamos usar la información almacenada en los archivos de bloqueo para hacer eso: https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33, tal vez agregar la lista de archivos para hacer una copia de seguridad o los argumentos exactos de la línea de comandos o algo similar.

Todavía no veo cómo resticiaría en la máquina A, encontrando un bloqueo en la máquina del servidor de respaldo B, distinguir entre a) la sesión restic actualmente en ejecución en la máquina C yb) el bloqueo obsoleto dejado después de que el restic en la máquina C se bloqueó?

¿O estamos empezando a hablar de mecanismos RPC aquí? ¿O mejor aún, administradores de bloqueo distribuidos? 😄

@zcalusic Estoy hablando del # 711: detectar cuando se inicia una segunda copia de seguridad con los mismos directorios en la misma máquina. Eso debería ser posible.

@bwmarrin No entiendo lo que estás sugiriendo:

Si sabe que su trabajo cron programa una copia de seguridad cada X horas, puede pasar un tiempo de espera a restic para que termine antes de que comience la siguiente.

Se ejecuta una copia de seguridad hasta el final o se cancela / termina. No creo que sea posible cronometrar de alguna manera una copia de seguridad que, como máximo, tome la duración que se dé en un parámetro hipotético --timeout . ¿Cómo podría funcionar eso?

¿Podría describir la semántica de dicho parámetro? ¡Gracias!

@ fd0 Estoy diciendo que si la copia de seguridad no termina dentro del valor --timeout, se termina. Me doy cuenta de que esto significa que sería una copia de seguridad incompleta o sin terminar. Sin embargo, dado que el diseño incremental de restic no es un gran problema. La próxima vez que se llame a la copia de seguridad, comenzará donde se quedó.

Esto significa que si tiene un trabajo cron programado para ejecutarse cada hora y pasa un parámetro --timeout 50m a restic. Anulará / terminará la copia de seguridad si tarda más de 50 minutos. En ese caso, 10 minutos después, el trabajo cron lo iniciará nuevamente y se reanudará donde lo dejó. Esto evitaría que se ejecuten simultáneamente varias instancias de la misma copia de seguridad.

Gracias por la explicación. Creo que esta no es una buena idea. ¿Qué sucede si la ubicación de la copia de seguridad es lenta sin que usted se dé cuenta (alguien en su red olvidó un cliente bittorrent, lo que maximiza su ancho de banda ascendente), por lo que la copia de seguridad no termina, se cancela, se reinicia nuevamente, se cancela nuevamente y así sucesivamente? . Entonces nunca terminará con una copia de seguridad de trabajo completa.

O considere un árbol de directorios para el que se agregan datos constantemente. Una sola ejecución de restic terminará eventualmente (está diseñado de esa manera), pero es posible que el reinicio de restic nunca termine cuando se agregan demasiados datos nuevos entre las ejecuciones.

Además, puede implementar fácilmente este comportamiento usando la utilidad estándar timeout (de coreutils), ejecutando timeout 40m restic backup [...] . Por lo tanto, no creo que agregar esta opción a Restic sea una buena idea.

Me doy cuenta de que llego tarde a la fiesta, pero ¿no podría haber un archivo de bloqueo que haga que la segunda instancia espere a que termine la primera antes de comenzar?

@ Karl-Gustav, quizás puedas lograrlo con un poco de programación. https://stackoverflow.com/a/1985512/244009

Eso fue un poco más avanzado que mis bloqueos :-) Solo uso if file {wait 5sec and check again}

Puede que llegue un poco tarde a la discusión, pero creé algunas unidades systemd que puedes encontrar aquí .
Estos son mis archivos de configuración restic, pueden ser útiles para alguien.

Hola, estoy leyendo sobre cómo usar restic para programar mis copias de seguridad. Por ahora, mi idea es usar anacron para programar, por ejemplo, una copia de seguridad de 2 días por semana en Backblaze. El caso es que, si mi copia de seguridad está programada con anacron, por ejemplo, martes y viernes a las 12 p.m. y mi computadora portátil se apaga el martes y no se inicia de nuevo hasta el viernes a las 11:59 a.m., ¿qué pasará? AFAIK (y si no me equivoco) anacron debería comenzar el trabajo perdido del martes; y un minuto después (mientras se ejecuta la primera instancia restic), ¿ejecutará la segunda copia de seguridad, produciendo 2 copias de seguridad simultáneas para el mismo directorio?

¿O es algún tipo de archivo de bloqueo / tmp para evitar que se ejecute la segunda instancia?
¿Cómo debo administrarlo para programar correctamente mi copia de seguridad? Gracias :)

@gerardbosch ¡Hola! Esta pregunta encaja mejor con el foro , considérala la próxima vez :)

Una forma de manejarlo es escribir un script que ejecute restic por usted, y como parte de hacerlo, cree un archivo de ejecución (por ejemplo, /var/run/restic.pid contenga el PID del proceso restic`), que luego puede compruebe para determinar si restic ya está funcionando o no.

No harm de ninguna manera si tuviera que ejecutar dos copias de seguridad simultáneas, pero, por supuesto, no tiene sentido si cubren más o menos los mismos archivos y un punto en el tiempo.

No sé si anacron intenta ponerse al día con las ejecuciones de copia de seguridad perdidas, supongo que debería decirlo en su documentación. Si está en macOS y usa launchd para programar, tiene la opción de hacerlo o no, depende de usted.

FYI para más personas que aterrizan aquí desde búsquedas de Google:

Así es como hago una copia de seguridad en un horario usando los servicios y horarios de systemd, en lugar de trabajos cron. También presenta notificaciones por correo electrónico cuando falla la copia de seguridad.

https://github.com/erikw/restic-systemd-automatic-backup

@erikw Fantástico guión de programación, ¡felicidades!
Algunas preguntas:

• ¿Cuál es la principal ventaja de usar temporizadores systemd sobre cron o anacron?
• ¿Se pueden instalar los scripts / setup de systemd en homedir en lugar de / etc?
• ¿Puede la pestaña anacron residir en algún lugar de $ HOME?

Estoy planeando hacer una copia de seguridad del directorio principal de mi computadora portátil, por lo que la copia de seguridad de los mismos scripts del programador proporcionará, en caso de recuperación de desastres, un sistema de copia de seguridad programado listo para usar (es decir, restaurar toda la copia de seguridad después del desastre) nueva cuenta de usuario ya configurada para realizar copias de seguridad en el mismo programa anterior).

@gerardbosch

• Si tiene un sistema systemd, es bastante bueno poder usar las herramientas predeterminadas, no es necesario instalar un demonio cron. Obtiene un gran control sobre el estado de los trabajos fallidos y puede ver cuándo se ejecutará un trabajo la próxima vez, por ejemplo. Consulte la wiki de arch para una breve introducción. Sin embargo, diría que simplemente jugar con él es la forma más divertida de aprender.

• Sí, ejecuto varios temporizadores systemd para mi usuario local. Revise mis archivos de --user para controlar los temporizadores del usuario en lugar de los temporizadores del sistema:

$ systemctl --user list-timers

• Parece que normalmente están en /var/spool . Si se puede mover a ~/ no lo sé. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

Como aún no se ha mencionado aquí, Backupninja es una excelente manera de manejar la programación. Se está agregando soporte Restic en una solicitud de fusión ; simplemente no se ha cometido todavía. Sin embargo, toda la funcionalidad básica debería estar ahí.

@colans Backupninja es increíble, ¡no puedo esperar para poder usarlo con restic! Gracias por este trabajo.

restic backup seguido de restic forget y restic prune es el flujo de trabajo habitual, y eso lo limpia. Agregaré otro problema de todos modos, para que podamos rastrear esta idea.

Si estoy configurando una tarea programada diaria / trabajo cron sin la expectativa de posibles trabajos paralelos, ¿debería el script seguir haciendo restic backup -> restic forget -> restic prune ? Parece que está agregando más gastos generales si solo estamos ejecutando una instancia a la vez

¿Podemos reabrir esto como una tarea de documentación? Creo que deberíamos agregar una sección "Programación" al manual para aumentar la claridad sobre este tema. Podemos decir algo como:

La programación está fuera del alcance de Restic. Sin embargo, existen herramientas externas que se pueden utilizar para este propósito.

• Backupninja junto con la rama de soporte de Restic
• Copias de seguridad automáticas mediante temporizadores y servicios de systemd
• Configuraciones de respaldo Restic

Pensamientos

Otras sugerencias para reabrir. Si restic no admite la programación / supervisión de copias de seguridad, los documentos pueden explicar esto y vincular a algo que sí lo haga, ya que esa es la forma principal en que se utilizan las herramientas de copia de seguridad.

@SigmaX cómo programar depende completamente del sistema operativo y software que tenga a su disposición. Creo que sugerencias como esa están fuera de la documentación por motivos de preocupación, pero de hecho podría ser un artículo útil en el blog de alguien o incluso en la sección de Recetas del foro. También podría ser un candidato para la sección de Ejemplos en el sitio web restic doc en https://restic.readthedocs.io/en/latest/080_examples.html , pero tendría que estar escrito de tal manera que requiera un mínimo de mantenimiento, ya que no queremos mantener un conjunto de instrucciones detalladas sobre cómo programar esto en varias plataformas diferentes (ya que es un tema bastante complejo). Dicho todo esto, ya hay varios artículos y ejemplos sobre esto (por ejemplo, con cron y systemd) en la red, si uno lo busca. No estoy del todo seguro de que sea necesario tener eso en el sitio web de documentos.

No estoy del todo seguro de que sea necesario tener eso en el sitio web de documentos.

Puedo ver cómo sería una cuestión de opinión, sobre todo porque restic es multiplataforma. Para mi fue sorprendente. Tener una herramienta de respaldo sin documentos destacados sobre cómo programarlo me parece como vender un automóvil sin ruedas. Pasé bastante tiempo buscando en los documentos, asumiendo que me faltaba algo. Nunca lanzaría una copia de seguridad manualmente, pero eso es todo lo que describen los documentos.

Como mínimo, una sección de documentos podría ahorrar tiempo a los usuarios: al indicarles que necesitan buscar en otro lugar / encontrar una herramienta diferente para configurar copias de seguridad de rutina con restic.

Tener una herramienta de respaldo sin documentos destacados sobre cómo programarlo me parece como vender un automóvil sin ruedas

Realmente no. Lo que le "vendemos" es un programa del que usted dice qué respaldar, y lo respalda. La frecuencia con la que quieres hacer eso es una preocupación separada :) Pero estoy divagando.

Esperaría que la mayoría de los usuarios, si no encuentran un tema determinado en los documentos, simplemente DDG / Google, encuentren las respuestas en uno o dos minutos. Pero eso no significa que no debamos agregar un puntero de algún tipo a la documentación, incluso si no detallamos detalles sobre cómo configurar varios programas de programación.

Lo que le "vendemos" es un programa del que usted dice qué respaldar, y lo respalda. La frecuencia con la que desea hacer eso es una preocupación separada :)

Y es perfectamente legítimo decir "este es un kit de bricolaje: ¡busque sus propias ruedas!"

Esperaría que la mayoría de los usuarios, si no encuentran un tema determinado en los documentos, simplemente DDG / Google, encuentren las respuestas en uno o dos minutos.

De hecho, buscar en Google el "horario de copia de seguridad restante" me trajo aquí el primer partido: sonrisa:

2122 está relacionado, ya que proporciona algunos temporizadores systemd de muestra y otra discusión sobre la programación.

Creo que el enfoque de "mínimo mantenimiento" aquí parece tener sentido ... ¿tal vez incluir sugerencias sobre el registro de salida y la prevención de múltiples ejecuciones al mismo tiempo?

¿Quizás incluir sugerencias sobre el registro de salida y la prevención de múltiples ejecuciones al mismo tiempo?

Me gusta esa idea. Haré un borrador más adelante esta semana, probablemente para una pequeña sección de "puntero" para colocar debajo de la sección de respaldo en la documentación.