Sauvegarde sur disque externe avec Borg ou Restic

Mon serveur YunoHost

Matériel: Microserveur HP
Version de YunoHost: 3.7.1.1
J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran |
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

Bonjour,
J’ai installé Yunohost sur mon serveur récemment et je souhaiterais mettre en place une sauvegarde régulière sur un disque externe.
J’ai regardé les applications Borg et Restic, mais elles ne proposent la sauvegarde que sur un autre serveur.
Est-il possible de configurer Borg ou Restic pour faire une sauvegarde sur un disque externe local ?

Merci pour votre réponse
Pancho

Oui c’est possible, il suffit de définir ton disque local pour les sauvegardes avec la commande:

borg init  /media/ton_disque/sauvegarde

Par contre je ne sais pas si c’est possible de le faire directement à partir de l’application, je ne l’ai jamais essayée, j’avais suivi les tuto de @ljf sur le forum pour mettre en place les scripts de sauvegarde dont celui-ci:

https://forum.yunohost.org/t/how-to-backup-automatically-with-borg-on-a-local-harddrive-without-encryption/4005

Dans ma todo list depuis des mois il est indiqué « FAIRE UN BACKUP !!! »
Je vais essayer de m’y mettre aujourd’hui pour voir.

A priori, en installant le client ET le serveur, avec Borg, tu peux faire une sauvegarde chez toi directement.

Bon, me voici de retour, bredouille :cry:
J’ai installé borg puis borgserver, l’un configuré vers l’autre, jusque là tout va bien.

de ce que j’ai pu trouver en creusant un peu (j’ouvrirai un ticket si c’est ça pour que l’info soit accessible), le dossier de sauvegarde est dans /home/borguser/backup (que j’ai fait pointer vers un disque externe)

J’ai voulu testes un backup tout simple pour commencer, avec juste une toute petite app (une webapp)
J’ai donc lancé
sudo service borg start

Puis sudo journalctl -xepour voir ce que ça donnait.
1er soucis, si je lance ça plusieurs fois, ça pète sur un dossier que je ne réussis pas à supprimer et que je renomme pour pouvoir lancer la commande : /home/yunohost.backup/tmp/auto_conf

Et j’ai alors ce message :

avril 27 13:18:46 monServeur.fr backup-with-borg[3601]: Échec de l’exécution du script : /etc/yunohost/hooks.d/backup_method/05-borg_app
avril 27 13:18:46 monServeur.fr backup-with-borg[3601]: Échec de la méthode de sauvegarde personnalisée à l’étape 'backup'
avril 27 13:18:50 monServeur.fr systemd[1]: Started Run backup borg.
-- Subject: L'unité (unit) borg.service a terminé son démarrage
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- L'unité (unit) borg.service a terminé son démarrage, avec le résultat done.

En parallèle j’ai un sudo tail -f /var/log/backup_borg.err de lancé pour avoir plus de détails et j’ai :

Remote: Debian GNU/Linux 9
Remote: bash: /usr/local/bin/borg: Permission non accordée
Connection closed by remote host. Is borg working on the server?
Remote: Debian GNU/Linux 9
Remote: bash: /usr/local/bin/borg: Permission non accordée
Connection closed by remote host. Is borg working on the server?

(Oui, 2x, avant c’était 4x mais j’ai ajouté borguser au groupe staff en espérant que ça change quelquechose)

Du coup, la, ça ne marche pas.

Note potentiellement utile : j’avais déjà essayé d’utiliser borg il y a quelques années, avant que les app existent, j’ai peut-être cassé quelquechose à ce moment la.

J’ai vu que les app installent borg via pip et que la version des paquets debian ne va pas, alors j’ai un peu cherché mais je ne sais pas comment vérifier ça.
Voilà ce que a été installé via apt :

~ sudo apt search borg
borg-ynh-deps/now 1.1.10~ynh1 all  [installé, local]
  Fake package for borg (YunoHost app) dependencies

borgbackup/oldstable 1.0.9-1 amd64
  deduplicating and compressing backup program

borgbackup-doc/oldstable 1.0.9-1 all
  deduplicating and compressing backup program (documentation)

borgserver-ynh-deps/now 1.1.10~ynh5 all  [installé, local]
  Fake package for borgserver (YunoHost app) dependencies

pip show borg ne me retourne rien, voici le pip search

~ pip search borg 
borg (2012.4.01)       - the borg algorithm portfolio toolkit
borgback (1.0)         - Scheduled backups using Borg

Si quelqu’un as une piste, ça m’intéresse.

Mouarf @ljf sauraient mieux que moi mais naivement, est-ce que tu le serveur distant tu peux faire un

ls -l /usr/local/bin/borg

(vu que visiblement c’est un probleme de permission on va regarder pourquoi on a pas le droit)

~ ls -l /usr/local/bin/borg
-rwxr--r-- 1 root staff 69 avril 27 11:28 /usr/local/bin/borg
~ sudo groups borguser
borguser : borguser staff

Et oui, visiblement, pas de droit d’exécution pour le groupe :smile:

Du coup ça a l’air de vachement mieux marcher, je regarde ce que je peux en faire maintenant :+1:

Bonjour,
Merci pour vos réponses et merci à @Mamie pour les tests complémentaires.
Je pense que je vais utiliser le tuto de @ljf qui a fait ses preuves.

Un petit retour une semaine plus tard (parce que j’avais configuré borg pour tourner toutes les semaines) : Semi-échec

Quand j’avais lancé à la main ( sudo service borg start) ça m’avait bien créé une sauvegarde par appli et une pour la conf.
Et la, une semaine après, j’ai 2 sauvegardes de plus

auto_borg_04_05_20_00:00
auto_borgserver_04_05_20_00:00

Toutes les deux toutes petites, et aucune nouvelle sauvegarde des applis sur mon serveur.

Les logs de borg sont vides, et les logs d’erreurs ne sont pas horodatés, du coup je ne sais pas si c’est lié ou non, mais voici les 10 dernières lignes :

Remote: Debian GNU/Linux 9
Remote: Debian GNU/Linux 9
Remote: Debian GNU/Linux 9
A repository already exists at ssh://borguser@monserveur.fr/~/backup.
Remote: Debian GNU/Linux 9
Remote: Debian GNU/Linux 9
Remote: Debian GNU/Linux 9
A repository already exists at ssh://borguser@monserveur.fr/~/backup.
Remote: Debian GNU/Linux 9
Remote: Debian GNU/Linux 9

Comme je suis une quiche, je tente un peu au pif pour trouver des infos utiles :

~ sudo systemctl status borg.timer 
● borg.timer - Run backup borg regularly
  Loaded: loaded (/etc/systemd/system/borg.timer; enabled; vendor preset: enabled)
  Active: active (waiting) since Mon 2020-04-27 11:35:46 CEST; 1 weeks 2 days ago
sudo systemctl status borg.service 
● borg.service - Run backup borg
   Loaded: loaded (/etc/systemd/system/borg.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2020-05-04 00:02:14 CEST; 2 days ago
 Main PID: 30639 (code=exited, status=1/FAILURE)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Bon, du coup :

~ sudo systemctl start borg.service
Job for borg.service failed because the control process exited with error code.
See "systemctl status borg.service" and "journalctl -xe" for details.
sudo systemctl status borg.service
● borg.service - Run backup borg
   Loaded: loaded (/etc/systemd/system/borg.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2020-05-06 13:21:02 CEST; 28s ago
  Process: 10564 ExecStart=/usr/local/bin/backup-with-borg (code=exited, status=1/FAILURE)
 Main PID: 10564 (code=exited, status=1/FAILURE)

mai 06 13:21:02 monserveur.fr backup-with-borg[10564]:     self._init_work_dir()
mai 06 13:21:02 monserveur.fr backup-with-borg[10564]:   File "/usr/lib/moulinette/yunohost/backup.py", line 341, in _init_work_dir
mai 06 13:21:02 monserveur.fr backup-with-borg[10564]:     filesystem.mkdir(self.work_dir, 0o750, parents=True, uid='admin')
mai 06 13:21:02 monserveur.fr backup-with-borg[10564]:   File "/usr/lib/python2.7/dist-packages/moulinette/utils/filesystem.py", line 248, in mkdir
mai 06 13:21:02 monserveur.fr backup-with-borg[10564]:     raise OSError(errno.EEXIST, m18n.g('folder_exists', path=path))
mai 06 13:21:02 monserveur.fr backup-with-borg[10564]: OSError: [Errno 17] Le dossier existe déjà : '/home/yunohost.backup/tmp/auto_wallabag2'
mai 06 13:21:02 monserveur.fr systemd[1]: borg.service: Main process exited, code=exited, status=1/FAILURE
mai 06 13:21:02 monserveur.fr systemd[1]: Failed to start Run backup borg.
mai 06 13:21:02 monserveur.fr systemd[1]: borg.service: Unit entered failed state.
mai 06 13:21:02 monserveur.fr systemd[1]: borg.service: Failed with result 'exit-code'.

Et la on se retrouve avec le dossier /home/yunohost.backup/tmp qui n’est pas vide et que je ne peux pas supprimer :

~ sudo rm -rf /home/yunohost.backup/tmp
rm: impossible de supprimer '/home/yunohost.backup/tmp/auto_lutim/apps/lutim/backup/var/www/lutim/LICENSE': Système de fichiers accessible en lecture seulement

(message d’erreur présent environ un milliard de fois)

Pourtant je suis en sudo.
Et juste pour voir :

sudo ls -alh /home/yunohost.backup/tmp/auto_lutim/apps/lutim/backup/var/www/lutim/
total 324K
drwxr-xr-x 12 lutim lutim 4,0K mai    6 07:00 .
drwxr-xr-x  3 root  root  4,0K avril 27 16:21 ..
[…]
-rw-rw-r--  1 lutim lutim  34K nov.  16 16:14 LICENSE
[…]

Je vais (encore) renommer le dossier pour pouvoir relancer une sauvegarde.

Je reviens dans quelques heures quand ça sera fini.

Et voilà, sauvegarde terminée, mais avec toujours le dossier /home/yunohost.backup/tmp non-vide et non-supprimable.
Les fois d’avant le dossier faisait quelques Ko, la il fait 19Go et c’est pas cool du tout comme « effet de bord »

Le bon point c’est que j’ai bien tous mes backups qui sont faits, avec de la déduplication qui fait plaisir (550Go de backup, dans 246Go dédupliqués)

Je doute qu’il fasse vraiment 19Go, à mon avis il est plein de mount–bind et de hardlink qui fausse le calcul du poids.

S’il te met que le système de fichiers est en lecture seule, c’est un problème de partition.
Tu peux écrire un fichier dans ton /home/yunohost.backup sur lequel tu sauvegardes ?
C’est bien ton disque externe qui est monté sur ce point de montage ?

touch /home/yunohost.backup.test

Ca marche ?
Ca ressemble plutôt à un problème de ce genre, pas de borg.

J’espère fortement que c’est une « fausse » taille, parce que la c’est monté à 265G :scream: (mais je pense que oui, l’espace disque a à peine varié lors du dernier backup)

J’ai pu créer un fichier dans /home/yunohost.backup sans soucis.
Petit détail au cas où, /home/yunohost.backup est un lien symbolique vers un disque externe (celui qui sert de backup, les sauvegardes de borg sont aussi sur ce disque)

Pour l’instant, je fais un sudo mv /home/yunohost.backup/tmp /home/yunohost.backup/tmp.old à la main pour que le prochain backup puisse se faire :frowning:
(Oui, toujours vers la même destination, ça n’a pas l’air de poser de problème)

Le lien symbolique il faut le faire sur /home/yunohost.backup/archives
Sinon tu ne bénéficies pas des optimisations concernant /home/yunohost.backup/tmp .
Logiquement si tu lances un backup ensuite, le dossier tmp précédent est supprimé si il est toujours là.

J’avais fait le lien pour tout le dossier pour éviter d’utiliser trop de place sur mon serveur, le disque racine est tout petit.
Je vais changer ça de ce pas et voir si tout explose :grin:

En fait le trucs c’est que borg nécessite que les fichiers soient organisés d’une certaines façon dans l’archive. Avec la méthode targz on peut facilement placer les fichier dans le bon endroit dans l’archive, mais avec borg il faut préparer un dossier qui soit agencé de la bonne façon.

Pour éviter de se retrouver à dupliquer les données, la méthode de backup borg va utiliser mount --bind et des hardlink pour organiser les contenus comme il faut sans avoir à les copier. Mais je suis sûr que les hardlink ne peuvent pas fonctionner si on est sur un autre disque. ET pour le mount --bind je ne sais plus trop.

A noter que le dossier tmp a quand même un poids réel, celui-ci est lié au dump des bases de données (mysql, postgresql et mongodb principalement). Mais logiquement ce n’est pas très lourd.

J’espère que ça marche entre les disques, parce que NextCloud a son disque rien que pour lui.
Transmission mets aussi ses fichier sur encore un autre disque, il faut que je pense à ne pas le sauvegarder, ranafout’ des backups d’ISO Linux…

En tous cas, le lien est fait, à dans une semaine pour voir comment ça se sera passé :smile:

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.