Ok, je vais essayer de tester quand je trouve le temps. Mais je suis plus intéressé par une sauvegarde locale directe, si tu arrives à l’intégrer au paquet, ça me semble un peu surdimensionné de passer par du sftp pour aller sur un disque local (même si je comprends bien l’idée de ce workaround pour le moment).
Salut @bleeh, je viens de faire un essai de backup local avec une 2ème instance de restic.
Ça a l’air de fonctionner, par contre ça ne backup pas les apps, alors que j’avais bien laissé “all” lors de l’installation :
conf_cron: Success
conf_ldap: Success
conf_mail: Success
conf_nginx: Success
conf_ssh: Success
conf_ssowat: Success
conf_xmpp: Success
conf_ynh_certs: Success
conf_ynh_currenthost: Success
conf_ynh_dyndns: Success
conf_ynh_firewall: Success
data_home: Success
data_mail: Success
Et étonnamment, les apps ne sont plus backupées non plus par mon backup distant, alors qu’il le faisait avant.
-» Edit : j’ai ça dans les logs : lamo backup-with-restic__2[14989]: ls: impossible d'accéder à '/etc/yunohost/apps/*/scripts/backup': Permission non accordée
Ça m’a permis de me rendre compte d’un autre problème : sur mon backup distant, qui est configuré depuis presque 1 an, il ne sauvegarde pas data_home et data_mail (pourquoi ?), et il ne sauvegarde pas toutes les apps, il manque nextcloud et je n’ai qu’une instance de wordpress sur 5.
Et est-ce qu’on peut aller voir et modifier à la main ce qui est sauvegardé par chaque instance ? Si oui, où ?
Merci !
Salut, effectivement je ne vois plus les applications dans l’e-mail de récapitulation et j’ai vérifié sur le serveur de destination il ne semble plus y avoir de sauvegarde des applications depuis que j’ai fait la mise à jour, je vérifie ça.
EDIT: J’ai trouvé d’ou vient le problème, en fait c’est une autre mise à jour que j’ai faite après le multi-instance qui a cassé le listing des apps, je tâche de trouver un moment dans la journée pour corriger.
Sinon pour voir la liste d’applications à sauvegarder, de mémoire c’est yunohost app setting restic apps (ou restic__2, faut mettre le nom de l’instance)
C’est corrigé et j’ai ajouté quelques commandes dans le readme (visible sur le projet github, faudrait que je voie comment créer la doc sur le site YNH), notamment comment lancer manuellement une vérification des sauvegardes et comment lister les applications qui seront sauvegardées.
Dans tous les cas quand il faut débugger, lance une sauvegarde (systemctl start restic - ou restic__2 ou autre selon le nom de l’instance) et vérifie le journal dans le même temps à partir d’un autre shell (journalctl -f -u restic - ou restic__2 ou autre blah blah blah…)
Merci, ça a l’air de marcher, mon backup local est en cours depuis ce matin (pas mal de données sur Nextcloud, ça prend du temps !).
Une idée pour les mails qui sont envoyés à chaque backup : est-ce qu’il serait possible d’indiquer ce qui n’est pas sauvegardé par le backup ? Actuellement il met tout ce qui est sauvegardé avec “success” si le backup a fonctionné, ça serait pas mal de mettre en bas tous les éléments non sauvegardés. Ça m’aurait permis de me rendre compte plus tôt que nextcloud n’était plus sauvegardé par exemple, ou que je n’avais qu’un wordpress de sauvegardé sur les 5 que j’ai.
Oui je sais c’est moyen, mais la c’est particulier, ce n’est pas la sauvegarde qui a merdé, c’était un problème de permissions pour une commande de listage des applications.
Je vais quand même réfléchir à ce problème.
C’est pas tant pour une sauvegarde qui merde ou pas (dans ce cas on a le success ou pas), c’est plutôt pour être alerté de ce qui n’est pas sauvegardé. Par exemple si on installe une nouvelle app et qu’on ne la pas ajouté à la liste, on le saura.
Autre chose à corriger : le mail quotidien des backups ne liste qu’une instance pour les applications multi-instances : j’ai 2 restic et 6 wordpress, mais dans la liste je ne vois que restic: Success et wordpress: Success. Pourtant, toutes les instances sont bien sauvegardées.
Et encore une question, j’arrive à accéder à mes sauvegardes distantes via Filezilla, mais je n’y arrive pas directement depuis mon serveur :
admin@servera:~$ restic -r sftp:serverb.fr:/backups/auto_wordpress__3 snapshots
admin@serverb.fr's password:
Il me demande un mot de passe, qui a l’air d’être le mot de passe du compte pour se connecter en ssh, alors que je me connecte par clé, comme indiqué sur le tuto sur github. Comment faire ?
J’ai aussi des éléments qui ne sont pas sauvegardés sur ma sauvegarde distante (que j’ai installée il y a plusieurs mois), et qui le sont bien dans la sauvegarde locale (nouvellement installée) :
- data_home et data_mail : si c’est le dossier qui s’appelle “auto_data”, ils sont bien sauvegardés, ils n’apparaissent juste pas dans le mail.
- nextcloud : Les derniers snapshots datent du 5 décembre 2020.
Les 2 sont bien configurés en “all” pour les apps à sauvegarder.
Ok, ça c’est une nouvelle fonctionalité, je la garde de côté mais pour l’instant je vais plutôt m’assurer que les erreurs remontent bien et clarifier les e-mails récapitulatifs.
C’est c’est un autre bug, tu devrais avoir un e-mail après chaque exécution de chaque instance, je vais regarder mais ça peut me prendre un peu de temps je dois remonter mon serveur de test qui est parti en fumée chez OVH…
Ok j’ai complètement lu de travers, ce n’est pas ce que tu disais.
Ça ça dépend du script de backup de chaque application je pense, je vériefierai mais puisque le backup fonctionne ça sera dans un second temps.
Les commandes restic sont lancées en sudo, les clefs privées sont donc chez root, essaye avec un sudo ou alors bascule en tant que root avant.
Vérifie tes derniers e-mails de vérification, ou alors s’ils sont trop anciens, lance une vérification (systemctl start restic_check.service) et lis l’e-mail.
Vérifie qu’il n’y a pas de problème avec un des dépôts.
Ça m’est déjà arrivé d’avoir des dépôts “lockés” (peut-être suite à une coupure de connexion internet pendant la sauvegarde ou je ne sais quelle autre problème) et j’ai dû les déverouiller.
NOTE: il n’y aucune gestion de conflits entre les instances de restic, fais gaffe à ne pas toutes les programmer en même temps (en tout cas si tu l’as fait et que ça fonctionne fais-le moi savoir)
Pour info ce que j’ai fait c’est aller sur mon serveur de destination (en tant que l’utilisateur défini pour la sauvegarde), dans le répertoire de sauvegarde, puis:
export RESTIC_PASSWORD='monmotdepasse' # note l'espace en début de ligne empêchant bash d'enregistrer la commande dans son historique, comme elle contient le mot de passe, c'est pas la panacée mais c'est plus sûr
for repo in $(ls -1);do echo -e "\n===== $repo =====\n"; restic -r $repo unlock;done
Comme ça je fais juste une passe sur tous les dépôts et je les déverouille, car autre chose que je dois améliorer dans l’e-mail de récapitulation du check c’est que le dépôt concerné n’est pas mentioné.
J’ajoute ça aussi à la liste.
Merci pour tous ces retours, je ne m’étais pas vraiment préoccupé du paquet car il suffisait pour mon besoin, de voir que ça sert à d’autres motive à l’améliorer.
Un chance en ce moment j’ai un peu de temps pour m’en occuper.
Accès ssh : effectivement en sudo ça fonctionne, c’était aussi bête que ça, merci ! Peut-être le préciser sur la page github ?
Lock : effectivement, j’ai ça dans les mails de check :
mars 06 03:16:36 server check-restic[13169]: unable to create lock in backend: repository is already locked by PID 24291 on server by root (UID 0, GID 0)
mars 06 03:16:36 server check-restic[13169]: lock was created at 2021-02-25 00:37:51 (218h38m44.893621671s ago)
mars 06 03:16:36 server check-restic[13169]: storage ID afcd73f6
mars 06 03:16:36 server check-restic[13169]: the `unlock` command can be used to remove stale locks
Par contre c’est dommage, dans les checks on n’a aucun info de quel dépôt il s’agit. En tout cas c’est délocké.
Et merci pour ton travail, cette app est top pour les backups ! Si je trouve le temps, j’essaierai de faire une page de doc, à défaut de pouvoir t’aider sur le code.
Dis-moi si tu préfères que je rapporte les erreurs/améliorations (s’il y en a d’autres) directement sur github plutôt que sur ce post ?
Oui j’ai listé ça comme amélioration à apporter.
Pour les retours, normalement il devrait y avoir une section “issues” sur le dépôt YunoHost mais pour une raison que j’ignore ça n’y est pas, seulement sur mon dépôt perso… Pour l’instant tu peux les créer sur mon dépôt perso donc.
Salut,
Encore quelques remarques sur les mails et les logs :
- pour l’instant quand j’ai des backups qui ne marchent pas, j’ai juste un mail avec rien dedans, je n’ai pas trace des erreurs. J’ai eu notamment mon espace distant qui était saturé, donc les backups ne se faisaient plus, et j’avais juste un mail vide. Voici un extrait de
/var/log/restic_backup_restic.errsur cette erreur : PrivateBin - dans les logs, il n’y a pas les dates et heures de chaque commande, est-ce que ça serait possible de les ajouter ? Ça aiderait pour s’y retrouver dedans.
- dans l’idéal, dans le mail de log, on devrait pouvoir trouver chaque app à sauvegarder avec marqué “success” ou “error” (pour l’instant j’ai soit “success” soit rien, pas de ligne pour l’app en question), et tout en bas pour mémoire la liste des apps non sauvegardées.
Mais sinon, maintenant que j’ai augmenté mon espace de stockage distant, j’ai bien mes 2 backups qui fonctionnent, un local et un distant, et avec limite d’upload sur le distant, ça marche très bien !
Un autre retour : ce soir je galère à accéder à mon serveur, et je me suis rendu compte que j’ai 2 processus, restic et restic__2 qui carburent pas mal, et que je download à fond depuis le serveur de mon backup distant.
Je pense que c’est le check complet du backup “restic_check_read_data” qui est en cours. Quand il lance ce check, du coup il télécharge toutes les données du backup, c’est ça ? Si je le laisse faire il y en a pour quelques jours, et ça me sature ma connexion !
Est-ce qu’on peut désactiver ces checks complets ? En supprimant /etc/systemd/system/restic_check_read_data.timer par exemple ?
Pour libérer ma bande passante, un sudo service restic stop n’a rien fait, j’ai du tuer les processus.
Dans le processus d’installation, on peut choisir la fréquence du check complet, est-ce qu’il faudrait laisser vide pour que ça ne le fasse jamais ? Et peut-être mettre un petit warning sur le fait que ça télécharge l’intégralité des données du backup à chaque check complet.
Tu peux désactiver la planification du check avec systemctl disable restic_check_read_data.timer;systemctl stop restic_check_read_data.timer. Sinon pour stopper le processus en cours, je pense qu’un systemctl stop restic_check_read_data.service aurait dû fonctionner.
Ceci-dit je te conseille de lancer ce check de temps en temps puisque c’est la seule façon de vérifier que tu pourras restaurer des sauvegardes à partir des fichiers distants.
Il me semble avoir fait mention du fait que le check complet peut-être long dans la doc, c’est peut-être pas assez mis en avant.
PS: remplace restic par restic__2 dans les commandes ci-dessus pour ta deuxième instance.
Salut,
C’est un super package que tu proposes @bleeh, un bon moyen de mettre en place Restic.
Pour ma part, je n’ai pas d’autre serveur avec un SFTP, mais j’ai pour le moment un compte Dropbox que j’utilise pour faire des backups.
J’ai proposé une modification à discuter pour permettre d’utiliser n’importe quel repo Restic, pas uniquement du SFTP. Ça a l’avantage de laisser l’utilisateur plus libre de la destination de sauvegarde, l’inconvénient d’être moins pratique pour ceux qui ont utilisé la sauvegarde SFTP car le setup automatique de la clé SSH est supprimé.
Il y a peut-être la possibilité de trouver un entre deux ? On pourrait peut-être exécuter des étapes d’installation en fonction de la destination de sauvegarde, détectée en scrutant l’URL du repo donnée.
Salut @pbernery
Je jetterai un oeil un de ces soirs à la PR, merci.
Il est tout à fait possible de conditionner l’installation des clés ssh à une variable, enfin je ne vois pas pourquoi ça ne serait pas possible.
Bonjour,
cela fait plusieurs semaines que j’essaie de faire tourner restic et les sauvegardes vers un NAS.
j’ai réussi à installer le fichier id_rsa_restic avec la clé.
Quand je lance la commande auto_conf j’ai ça
admin@serveur:~$ sudo restic -r sftp:82.XX.XX.XX:monserveur.fr/auto_conf snapshots subprocess ssh: ssh: connect to host 82.XX.XX.XX port 22: Connection timed out
Fatal: unable to open repo at sftp:82.XX.XX.XX:monserveur.fr/auto_conf: unable to start the sftp session, error: EOF
Si quelqu’un à une idée ou si c’est juste pas possible vers un NAS je suis preneur.
Merci
Il n’y a pas de raison que ça ne fonctionne pas du moment que tu peux te connecter en sftp avec clé ssh sur ton NAS.
Tout d’abord, il faut vérifier que le sftp fonctionne bien, ensuite on verra pour restic.
Vu ton message d’erreur:
- soit le serveur sftp de ton NAS n’écoute pas sur le port 22 (ou ton nas n’a pas de serveur ssh/sftp actif), il va falloir aller vérifier dans la configuration de ton NAS
- soit tu n’as pas ouvert le port 22 et fait la redirection vers ton NAS.
Là c’est dans la configuration de ton routeur (box Internet) qu’il va falloir aller voir.
Pour savoir si le port est ouvert fais depuis ton serveur YNH:
telnet 82.XX.XX.XX 22
Tu devrais avoir un message du style Connected to 82.XX.XX.XX...
PS: Je ne sais pas si telnet est dispo par défaut sur YNH, si ce n’est pas le cas, tu peux aussi utiliser nc:
nc -zv 82.XX.XX.XX 22
# devrait renvoyer: Connection to 82.XX.XX.XX 22 port [tcp/*] succeeded!
Et si tu n’as pas nc non plus, tu peux toujours utiliser un outil du genre https://portchecker.co/ pour vérifier si le port 22 est ouvert
Salut Bleeh,
Déjà merci pour ton retour !!
Alors, j’ai bien la connexion SSH sur le NAS, j’ai ouvert les ports de la BOX, part acquis de conscience je viens de faire le test avec nc
> admin@serveur:~$ nc -zv 82.XX.XX.XX 22
> Connection to 82.XX.XX.XX 22 port [tcp/ssh] succeeded!
J’ai réussi la commande
restic -r sftp:mytargetserver:/home/backup/mysourceserver.mysourcedomain.tld/test-repository init
Je me demande si ce n’est pas le profil root qui est rejeté car il n’existe pas sur le NAS ?
Enfin, je te mets des infos, mais je préfère continuer à la docteur House, un pas après l’autre, tout le monde ment, il faut tout vérifier 