Selon cela , vous pouvez utiliser la variable d'environnement RESTIC_PASSWORD pour spécifier le mot de passe.

Comme @pvgoran l'a déjà dit, vous pouvez utiliser la variable d'environnement RESTIC_PASSWORD . Ceci est documenté dans le manuel ici http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository. Si vous avez une idée sur la façon de mieux documenter cela, veuillez créer une pull-request.

Il y a aussi le problème # 278, qui concerne la lecture du mot de passe à partir d'un fichier.

Je vais clore ce problème car il n'y a rien à faire pour le moment. Si vous n'êtes pas d'accord, veuillez laisser un commentaire.

Aïe, et je pensais avoir lu cette section à travers ...

Peut-être donner à ce paragraphe son propre titre ou sous-titre? Les quatre premiers paragraphes de cette section couvrent tout ce qui concerne l'initialisation d'un référentiel. L'automatisation des sauvegardes ne rentre pas vraiment dans ce domaine.

Merci @pvgoran pour la réponse rapide, btw. :sourire:

Juste une petite question complémentaire à ce sujet. Si une sauvegarde ne se termine pas au moment où cron exécute à nouveau la restic, que se passe-t-il?

Dans ce cas, restic démarrera une seconde sauvegarde (parallèle), qui utilise les données déjà téléchargées par la première sauvegarde (toujours en cours). Je suppose que les deux sauvegardes se termineront presque en même temps. Il y aura une duplication de données, qui sera nettoyée lors de la prochaine exécution de la commande prune . Cependant, cela ne causera aucune corruption ou perte de données. Le format du référentiel est conçu de manière à permettre le téléchargement parallèle des données.

C'est un cas intéressant auquel je n'ai pas encore pensé. Pensez-vous que nous avons besoin de code pour vérifier si la même sauvegarde est déjà en cours d'exécution sur le même hôte et quitter dans ce cas?

@ fd0 Peut-être, oui. Pour la même sauvegarde uniquement. Ou, une manière propre de script des sauvegardes automatisées: certaines instructions feront l'affaire, peut-être "restic backup" puis "restic unlock" puis "restic prune" par exemple. Mais ne pas avoir à se soucier de ces commandes supplémentaires serait bien.

restic backup suivi de restic forget et restic prune est le flux de travail habituel, et cela le nettoie. J'ajouterai quand même un autre problème, afin que nous puissions suivre cette idée.

Cool merci! Pour l'instant, je vais utiliser ce flux.

Une autre option ici qui pourrait aider est un paramètre de délai d'expiration. Si vous savez que votre tâche cron planifie une sauvegarde toutes les X heures, vous pouvez passer un --timeout à restic afin qu'il se termine avant le début de la suivante. Ce serait également pratique pour d'autres choses. (cela peut déjà exister, je suis nouveau au restic)

Détecter que restic fonctionne déjà semble délicat et je ne sais pas comment cela serait fait avec précision et propreté à partir de restic lui-même. D'autant plus que vous pourriez avoir différentes sauvegardes de restic en même temps qui ne devraient pas compter.

Peut-être un script de démarrage similaire à de nombreux autres scripts de démarrage Linux qui prend le PID de restic au démarrage et l'enregistre dans un fichier tmp puis le supprime à la fin de restic. Chaque fois que le script est exécuté, il recherche le fichier. Vous auriez besoin d'un fichier tmp différent pour chaque sauvegarde planifiée unique.

Malheureusement, tout moyen de détecter une instance de restic en cours échouerait sur TOUS les backends (SFTP, REST, S3 ...) sauf le local.

@zcalusic nous pourrions utiliser les informations stockées dans les fichiers de verrouillage pour ce faire: https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33, peut-être ajouter la liste des fichiers pour sauvegarder ou les arguments exacts de la ligne de commande ou quelque chose de similaire.

Je ne vois toujours pas comment relier la machine A, trouver un verrou sur la machine serveur de sauvegarde B, faire la distinction entre a) la session de restic en cours d'exécution sur la machine C et b) le verrou périmé laissé après le plantage de la restic sur la machine C?

Ou commençons-nous à parler de mécanismes RPC ici? Ou mieux encore, des gestionnaires de serrures distribués? 😄

@zcalusic Je parle de # 711: détecter quand une deuxième sauvegarde avec les mêmes répertoires sur la même machine est lancée. Cela devrait être possible.

@bwmarrin Je ne comprends pas ce que vous suggérez:

Si vous savez que votre tâche cron planifie une sauvegarde toutes les X heures, vous pouvez passer un --timeout à restic afin qu'il se termine avant le début de la suivante.

Soit une sauvegarde est exécutée jusqu'à la fin, soit elle est annulée / terminée. Je ne pense pas qu'il soit possible de chronométrer une sauvegarde de manière à ce qu'elle prenne au maximum la durée donnée dans un paramètre hypothétique --timeout . Comment cela pourrait-il fonctionner?

Pouvez-vous décrire la sémantique d'un tel paramètre? Merci!

@ fd0 Je dis que si la sauvegarde ne se termine pas dans la valeur --timeout, elle est terminée. Je réalise que cela signifie que ce serait une sauvegarde incomplète ou inachevée. Cependant, depuis la conception incrémentielle de Restic, ce n'est pas vraiment un gros problème. La prochaine fois que la sauvegarde sera appelée, elle commencera là où elle s'était arrêtée.

Cela signifie que si vous avez une tâche cron planifiée pour s'exécuter toutes les heures, et que vous passez un paramètre --timeout 50m à restic. Il abandonnera / mettra fin à la sauvegarde si cela prend plus de 50 minutes. Dans ce cas, 10 minutes plus tard, le travail cron le redémarrera et reprendra là où il s'était arrêté. Cela empêcherait plusieurs instances de la même sauvegarde de s'exécuter simultanément.

Merci pour l'explication. Je pense que ce n'est pas une bonne idée. Que se passe-t-il si l'emplacement de sauvegarde est lent sans que vous ne vous en rendiez compte (quelqu'un dans votre réseau a oublié un client bittorrent, qui vous maximise la bande passante en amont), de sorte que la sauvegarde ne se termine pas, est abandonnée, redémarre à nouveau, est à nouveau abandonnée et ainsi de suite . Ensuite, vous ne vous retrouvez jamais avec une sauvegarde complète.

Ou considérez une arborescence de répertoires pour laquelle des données sont constamment ajoutées. Une seule exécution de restic finira par se terminer (elle est conçue de cette manière), mais le redémarrage de restic peut ne jamais se terminer lorsque trop de nouvelles données sont ajoutées entre les analyses.

De plus, vous pouvez facilement implémenter ce comportement en utilisant l'utilitaire standard timeout (de coreutils), en exécutant timeout 40m restic backup [...] . Je ne pense donc pas que l'ajout de cette option à restic soit une bonne idée.

Je me rends compte que je suis en retard à la fête mais ne pourrait-il pas y avoir un fichier de verrouillage qui oblige la deuxième instance à attendre que la première se termine avant de commencer?

@ Karl-Gustav, vous pouvez peut-être y parvenir avec un peu de script. https://stackoverflow.com/a/1985512/244009

C'était un peu plus avancé que mes serrures :-) J'utilise juste if file {wait 5sec and check again}

Je suis peut-être un peu en retard dans la discussion, mais j'ai créé des unités systemd que vous pouvez trouver ici .
Ce sont mes fichiers de configuration restic, ils peuvent être utiles pour quelqu'un.

Salut, je lis comment utiliser Restic pour planifier mes sauvegardes. Pour l'instant, mon idée est d'utiliser anacron pour planifier par exemple une sauvegarde de 2 jours par semaine sur Backblaze. Le fait est que si ma sauvegarde est planifiée avec anacron, par exemple mardi et vendredi à 12 h et que mon ordinateur portable est éteint mardi et ne la redémarre pas avant vendredi à 11 h 59, que se passera-t-il? AFAIK (et si je ne me trompe pas) anacron devrait commencer le travail manqué de mardi; et une minute plus tard (pendant que la première instance de restic est en cours d'exécution), exécutera la deuxième sauvegarde, produisant 2 sauvegardes simultanées pour le même répertoire?

Ou est-ce une sorte de fichier de verrouillage / tmp pour empêcher la deuxième instance de s'exécuter?
Comment dois-je le gérer pour planifier correctement ma sauvegarde? THX :)

@gerardbosch Salut! Cette question convient mieux au forum , veuillez la considérer la prochaine fois :)

Une façon de gérer cela est d'écrire un script qui exécute le restic pour vous, et dans ce cadre, crée un fichier d'exécution (par exemple /var/run/restic.pid contenant le PID du processus restic`), qu'il peut ensuite Vérifiez si le restic fonctionne déjà ou non.

Ce ne sera en aucun cas harm si vous exécutez deux sauvegardes simultanées, mais c'est bien sûr plutôt inutile si elles couvrent plus ou moins les mêmes fichiers et à un moment précis.

Si anacron essaie de rattraper les sauvegardes manquées, je ne sais pas, il devrait le dire dans sa documentation, je suppose. Si vous êtes sur macOS et utilisez launchd pour la planification, vous avez la possibilité de le faire ou non, c'est à vous de décider.

FYI pour plus de personnes qui arrivent ici à partir des recherches Google:

Voici comment faire une sauvegarde selon un calendrier en utilisant les services et les heures de systemd, au lieu de tâches cron. Comprend également des notifications par e-mail lorsque la sauvegarde échoue.

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

@erikw Script d' horaire fantastique, félicitations!
Quelques questions:

• Quel est le principal avantage de l'utilisation des minuteries systemd par rapport à cron ou anacron?
• Les scripts / setup de systemd peuvent-ils être installés dans homedir au lieu de / etc?
• L'onglet anacron peut-il résider quelque part dans $ HOME?

Je prévois de sauvegarder le homedir de mon ordinateur portable, donc la sauvegarde des mêmes scripts de planificateur fournira en cas de reprise après sinistre, un système de sauvegarde planifié prêt à l'emploi (c'est-à-dire la restauration de toute la sauvegarde après le sinistre, fournira un nouveau compte utilisateur déjà configuré pour effectuer une sauvegarde selon le même calendrier précédent).

@gerardbosch

• Si vous avez un système systemd, c'est assez agréable de pouvoir utiliser les outils par défaut, pas besoin d'installer un démon cron. Vous bénéficiez d'un excellent contrôle sur l'état des tâches ayant échoué et vous pouvez voir quand une tâche sera exécutée la prochaine fois, par exemple. Voir le wiki arch pour une courte introduction. Je dirais cependant que jouer avec soi-même est la façon la plus amusante d'apprendre.

• Oui, j'exécute plusieurs minuteries systemd pour mon utilisateur local. Vérifiez mes fichiers dotfiles pour les minuteries et les services correspondants que j'utilise actuellement. La clé est d'utiliser --user pour contrôler les minuteries de l'utilisateur au lieu des minuteries système:

$ systemctl --user list-timers

• Il semble qu'ils soient généralement en /var/spool . Si le peut être déplacé vers ~/ je ne sais pas. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

Comme cela n'a pas encore été mentionné ici, Backupninja est un excellent moyen de gérer la planification. Le support Restic est ajouté dans une demande de fusion ; il n'a tout simplement pas encore été commis. Toutes les fonctionnalités de base devraient cependant être là.

@colans Backupninja est génial, j'ai hâte de pouvoir l'utiliser avec Restic! Merci pour ce travail.

restic backup suivi de restic forget et restic prune est le flux de travail habituel, et cela le nettoie. J'ajouterai quand même un autre problème, afin que nous puissions suivre cette idée.

Si je configure une tâche / tâche cron planifiée quotidiennement sans attendre d'éventuelles tâches parallèles, le script doit-il toujours faire restic backup -> restic forget -> restic prune ? On dirait que cela ajoute plus de frais généraux si nous n'exécutons qu'une seule instance à la fois

Pouvons-nous rouvrir cela comme une tâche de documentation? Je pense que nous devrions ajouter une section «Planification» au manuel pour clarifier ce sujet. Nous pouvons dire quelque chose comme:

La planification est en dehors de la portée de Restic. Cependant, il existe des outils externes qui peuvent être utilisés à cette fin.

• Backupninja avec la branche de support Restic
• Sauvegardes automatiques de restic à l'aide des services et des minuteries systemd
• Configurations de sauvegarde de restauration

Pensées?

Une autre suggestion à rouvrir. Si restic ne prend pas en charge la planification / la surveillance des sauvegardes, la documentation peut l'expliquer et établir un lien vers quelque chose qui le fait, car c'est la principale façon dont les outils de sauvegarde sont utilisés.

La planification de @SigmaX dépend entièrement du système d'exploitation et des logiciels dont vous disposez. Je pense que des suggestions comme celles-ci sont en dehors de la documentation pour les problèmes de restic, mais cela pourrait en effet être un article utile dans le blog de quelqu'un ou même dans la section Recettes du forum. Il pourrait également être candidat pour la section Exemples du site Web de restic doc à https://restic.readthedocs.io/en/latest/080_examples.html , mais il devrait être écrit de telle manière qu'il nécessite un minimum de maintenance, car nous ne voulons pas maintenir un ensemble d'instructions détaillées sur la façon de planifier cela sur plusieurs plates-formes différentes (car c'est un sujet assez complexe). Cela dit, il y a déjà plusieurs articles et exemples à ce sujet (par exemple avec cron et systemd) sur le net, si on le recherche. Je ne suis pas tout à fait sûr que cela soit nécessaire sur le site Web de la documentation.

Je ne suis pas tout à fait sûr que cela soit nécessaire sur le site Web de la documentation.

Je vois en quoi ce serait une question d'opinion, d'autant plus que restic est multi-plateforme. Pour moi, c'était surprenant. Avoir un outil de sauvegarde sans documents importants sur la façon de planifier cela me semble comme vendre une voiture sans roues. J'ai passé un certain temps à chercher les documents, en supposant qu'il me manquait quelque chose. Je ne lancerais jamais une sauvegarde manuellement, mais c'est tout ce que la documentation décrit.

À tout le moins, une section de documentation pourrait faire gagner du temps aux utilisateurs: en indiquant qu'ils doivent chercher ailleurs / trouver un outil différent pour configurer les sauvegardes de routine avec restic.

Avoir un outil de sauvegarde sans documents importants sur la façon de planifier cela me semble comme vendre une voiture sans roues

Pas vraiment. Ce que nous vous «vendons», c'est un programme qui vous dit quoi sauvegarder, et il le sauvegarde. Combien de fois vous voulez faire cela est une préoccupation distincte :) Mais je m'éloigne du sujet.

Je m'attendrais à ce que la plupart des utilisateurs, s'ils ne trouvent pas un certain sujet dans la documentation, se contentent de DDG / Google pour cela, puis trouvent les réponses en une minute ou deux. Mais cela ne signifie pas que nous ne devrions pas ajouter un pointeur quelconque à la documentation, même si nous ne détaillons pas les détails sur la configuration de divers logiciels de planification.

Ce que nous vous «vendons», c'est un programme qui vous dit quoi sauvegarder, et il le sauvegarde. La fréquence à laquelle vous voulez faire cela est une préoccupation distincte :)

Et il est parfaitement légitime de dire "ceci est un kit de bricolage --- allez trouver vos propres roues!"

Je m'attendrais à ce que la plupart des utilisateurs, s'ils ne trouvent pas un certain sujet dans la documentation, se contentent de DDG / Google pour cela, puis trouvent les réponses en une minute ou deux.

En fait, chercher sur Google "le calendrier de sauvegarde de restic" m'a amené ici le premier match: sourire:

2122 est lié car il fournit des exemples de temporisateurs systemd et d'autres discussions concernant la planification.

Je pense que l'approche du "moindre entretien" semble avoir du sens ... peut-être inclure des conseils sur la journalisation de la sortie et la prévention de plusieurs exécutions en même temps?

peut-être inclure des conseils sur la journalisation de la sortie et la prévention de plusieurs exécutions en même temps?

J'aime cette idée. Je ferai un brouillon plus tard cette semaine, très probablement pour une petite section "pointeur" à placer sous la section sauvegarde dans la documentation.