Borg backup ne sauvegarde pas en local (suspecte les permissions)

,

:fr: Problème de backups avec borg (permissions ?)

Mon serveur YunoHost

Matériel: Vieil ordinateur
Version de YunoHost: 4.2.8
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer: j’ai un disque dur interne monté en local utilisé pour les sauvegardes.

Description du problème

J’ai installé borg sur mon serveur et je souhaite faire une sauvegarde sur un disque dur interne dédié aux sauvegardes (donc ce n’est pas le même disque dur que celui où est installé Yunohost). J’ai donné le lien vers mon disque /media/HDD/backups et j’ai programmé en Daily. Mais depuis, je n’ai rien dans le dossier. Pourtant le diagnostic Yunohost ne détecte rien d’anormal pour borg.

Je me demande s’il n’y a pas de problème de permissions. En effet, dans cette discussion github, un membre de l’équipe dit qu’il faut s’assurer de mettre les bonnes permissions, mais sans dire lesquelles :

Savez-vous quel user:group doit avoir accès à ce dossier ou bien quel chmod utiliser svp ? Merci !

OK finalement le backup se lance à 00:00 si je ne me trompe pas. Ceci dit, il est anormalement petit en taille (2,6MB), voici le contenu du dossier /media/HDD/backups qui n’a pas bougé depuis un petit moment :

total 2,6M
drwxr-xr-x 3 root root    4,0K sept. 24 00:06 .
drwx------ 4 1000 ssh.app 4,0K sept. 23 00:47 ..
-rw------- 1 root root     700 sept. 24 00:00 config
drwx------ 3 root root    4,0K sept. 24 00:00 data
-rw------- 1 root root      64 sept. 24 00:04 hints.45
-rw------- 1 root root    2,6M sept. 24 00:04 index.45
-rw------- 1 root root     190 sept. 24 00:04 integrity.45
-rw------- 1 root root      16 sept. 24 00:04 nonce
-rw------- 1 root root      73 sept. 24 00:00 README

Et le répertoire data/ semble vide :

total 12K
drwx------ 3 root root 4,0K sept. 24 00:00 .
drwxr-xr-x 3 root root 4,0K sept. 24 00:06 ..
drwx------ 2 root root 4,0K sept. 24 00:04 0

Question bête, mais mieux vaut la poser : tu es en root pour voir ces infos ?
Tu n’a peut être juste pas accès en lecture au contenu du dossier, et du coup pour ton utilisateur il est vide.
Si je ne me trompe pas, la sauvegarde est lancée avec l’utilisateur root, du coup grosso modo, il a accès à tout, et le repo de sauvegarde a l’air d’avoir été créé.

Normalement, tu reçoit un mail en cas d’erreur (tu peux aussi configurer pour avoir un mail en cas de succès, et entre-autre dans ce mail ça dit la quantité de données sauvegardées.
Voici ce que j’ai dans le mail d’hier soir :

Collecte des fichiers devant être sauvegardés pour nextcloud…
Loading installation settings…
Declaring files to be backed up…
Backing up the MySQL database…
Backing up data directory…
Backup script completed for nextcloud. (YunoHost will then actually copy those files to the archive).
Création d’une archive de sauvegarde à partir des fichiers collectés…
L’archive contiendra environ 400.1GiB de données.
Sauvegarde terminée
name: auto_nextcloud
results:
apps:
nextcloud: Success
system:
size: 429633506853

1 Like

Merci Mamie pour ton aide détaillée !

Alors pour répondre à ta question : oui je suis bien en root dans la liste de fichiers que j’ai affiché précédemment. J’ai testé sudo et même sudo su pour être sûr.

Concernant les mails je n’en ai reçu qu’un seul (au début j’étais trop content !) et j’ai un peu déchanté en voyant que ça ne sauvegardait pas entièrement. Voici le mail reçu :

from : root
to : root@domaine.com
subject : [YUNOHOST] First backup is starting

Hello,

Your first backup on /media/HDD/backups is starting.

This is an automated message from your beloved Yunohost server.

On a pas du tout la même chose… peut-être que mon borg est pas content parce que je ne lui donne pas 400GiB à manger haha !

Est-ce qu’il existe un moyen de savoir ce que je lui ai demandé de sauvegarder ? Peut-être que je n’ai rien sélectionné et qu’il a sauvegardé “à vide”, qu’en penses-tu ?

Pour savoir ce qu’il y a comme backup:

borg list /media/HDD/backups
borg info /media/HDD/backups
1 Like

Merci de ton aide. Voici le résultat (étrange) de ces commandes :

-> sudo borg info /media/HDD/backups
Enter passphrase for key /media/HDD/backups: 
Repository ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Location: /media/HDD/backups
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Security dir: /root/.config/borg/security/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                1.78 GB            850.19 MB            285.69 MB

                       Unique chunks         Total chunks
Chunk index:                   40089               143360
-> sudo borg list /media/HDD/backups
Enter passphrase for key /media/HDD/backups: 
_auto_conf-2021-09-24_00:00          Fri, 2021-09-24 00:00:13 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_data-2021-09-24_00:00          Fri, 2021-09-24 00:00:29 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_borg-2021-09-24_00:00          Fri, 2021-09-24 00:00:45 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_jellyfin-2021-09-24_00:00      Fri, 2021-09-24 00:01:00 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_jirafeau-2021-09-24_00:01      Fri, 2021-09-24 00:01:15 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_lstu-2021-09-24_00:01          Fri, 2021-09-24 00:01:30 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_pihole-2021-09-24_00:01        Fri, 2021-09-24 00:01:56 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_roundcube-2021-09-24_00:02     Fri, 2021-09-24 00:02:12 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_searx-2021-09-24_00:02         Fri, 2021-09-24 00:02:41 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_wikijs-2021-09-24_00:03        Fri, 2021-09-24 00:03:11 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_wireguard-2021-09-24_00:04     Fri, 2021-09-24 00:04:22 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_conf-2021-09-25_00:00          Sat, 2021-09-25 00:00:18 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_data-2021-09-25_00:00          Sat, 2021-09-25 00:00:36 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_borg-2021-09-25_00:00          Sat, 2021-09-25 00:00:53 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_jellyfin-2021-09-25_00:01      Sat, 2021-09-25 00:01:10 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_jirafeau-2021-09-25_00:01      Sat, 2021-09-25 00:01:26 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_lstu-2021-09-25_00:01          Sat, 2021-09-25 00:01:43 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_pihole-2021-09-25_00:02        Sat, 2021-09-25 00:02:04 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_roundcube-2021-09-25_00:02     Sat, 2021-09-25 00:02:23 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_searx-2021-09-25_00:02         Sat, 2021-09-25 00:02:41 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_wikijs-2021-09-25_00:02        Sat, 2021-09-25 00:03:00 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_wireguard-2021-09-25_00:03     Sat, 2021-09-25 00:03:33 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_conf-2021-09-26_00:00          Sun, 2021-09-26 00:00:19 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_data-2021-09-26_00:00          Sun, 2021-09-26 00:00:38 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_borg-2021-09-26_00:00          Sun, 2021-09-26 00:00:55 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_jellyfin-2021-09-26_00:01      Sun, 2021-09-26 00:01:13 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_jirafeau-2021-09-26_00:01      Sun, 2021-09-26 00:01:30 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_lstu-2021-09-26_00:01          Sun, 2021-09-26 00:01:47 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_pihole-2021-09-26_00:02        Sun, 2021-09-26 00:02:09 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_roundcube-2021-09-26_00:02     Sun, 2021-09-26 00:02:26 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_searx-2021-09-26_00:02         Sun, 2021-09-26 00:02:45 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_wikijs-2021-09-26_00:03        Sun, 2021-09-26 00:03:04 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
_auto_wireguard-2021-09-26_00:03     Sun, 2021-09-26 00:03:36 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

Donc, on a bien un listing de backups (de taille 850.19 MB en mode compressée). Pourtant, si je fais :

-> df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               3,9G       0  3,9G   0% /dev
tmpfs              787M     82M  706M  11% /run
/dev/sda6          116G    5,8G  105G   6% /
tmpfs              3,9G    1,4M  3,9G   1% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              3,9G       0  3,9G   0% /sys/fs/cgroup
/dev/sda1          232M     99M  118M  46% /boot
/dev/sdb1          458G    277M  434G   1% /media/HDD
tmpfs              787M       0  787M   0% /run/user/991
tmpfs              787M       0  787M   0% /run/user/1007

Je n’ai que 227MB d’utilisé sur mon disque HDD. Pire encore, le diagnostique Yunohost me dit que mon disque HDD a 0% d’utilisé. Du coup je comprends rien. Les applis sont-elles sauvegardées au bon endroit ?

À moins que ce qui compte est ce qui est considéré comme Deduplicated size (et là ça correspondrait plus ou moins (285.69 MB vs 227MB) ?

Merci

C’est ça sauf que dans ta commande df -h, c’est 277MB et non pas 227MB. Il est fort probable que la différence de 8MB soit liée à la différence entre MiB et MB.

1 Like

Pour recevoir un mail à chaque sauvegarde, même en cas de succès :

Et pour en dire un peu plus sur borg, d’un côté il compresse les données, mais en plus il les “dé-duplique”, pour faire simple si tu as un fichier qui est plusieurs fois dans une sauvegarde, ou qui est sauvegardé plusieurs fois, il ne prendra sa place qu’une seule fois.
C’est grace à ça que je peux sauvegarder 400Go tous les jours, c’est pour etre sur de ne pas perdre plus de 24h de boulot, mais ça ne prends pas plus de place.

Autre note utile : tu peux avoir plusieurs process borg qui pointent vers le même repo.
Chez moi j’ai nextcloud et la conf générale sauvegardés tous les jours, et le reste une fois par semaine.
Note utile 2 : 2 applis borg peuvent travailler sur le même repo, mais pas en même temps, il faut jouer avec les heures de sauvegarde pour qu’ils passent l’un après l’autre.

2 Likes

Attention toutefois, si ça marche sans doute très bien pour sauvegarder la même machine, il est déconseillé (d’un point de vue performance) de sauvegarder des machines différentes avec un même repo borg. Enfin c’est la doc de borgbackup qui dit ça je sais plus trop où, j’ai pas d’idée par contre sur le temps supplémentaire de calcul que ça implique (ça dépend probablement de la quantité de données dans le repo et sur la machine).

Merci bien vu ! ah tu sais à 1 heure du matin passé, on n’est plus lucide !

@Mamie : encore toi pour m’aider, merci beaucoup ! J’ai effectivement le souvenir d’avoir paramétré les alertes que si il existait un souci. J’ai donc utilisé ta commande SSH pour être sûr d’avoir l’alerte même quand ça se passe bien.

À noter que j’ai lu quelque part (j’espère que mes souvenirs ne me trompent pas) que l’équipe Yunohost pense à intégrer Borg comme gestionnaire de sauvegarde par défaut au lieu des sauvegardes actuelles. Si tel était le cas, ce serait super d’avoir une interface facile comme Yunohost sait le faire avec juste le chemin de sauvegarde, la fréquence de sauvegarde, la gestion des alertes, et une partie restauration de sauvegarde.

Je marque le sujet comme résolu, vous êtes au top, merci pour tout !

Si j’ai bien tout suivi, oui, dans de futur ça sera intégré.
Mais à moins long terme, la prochaine version de YunoHost permettra aux apps de proposer une belle interface de configuration :+1:

1 Like

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