Je souhaitai faire backup total de YunuHost… avec beaucoup de data…
En interface web ça plante… J’ai donc fait en ligne de commande:
$ sudo yunohost backup create
…
Info: [###+++…] > Backing up the main app directory…
Info: [######++++…] > Backing up nginx web server configuration…
Info: [##########+++…] > Backing up php-fpm configuration…
Info: [#############+++…] > Backing up the MySQL database…
Info: Now creating a backup archive from the files collected…
Killed
$
$
Je suppose que c’est pas bon…
Il existe toujours le repertoire yunohost.backup/tmp/20191227-130921/
qui contient des fichiers… Je me dis qu’il aurait dû le supprimer une fois le backup terminé! Non ?
J’ai donc créé un fichier d’échange de 2Go… ça fonctionné… le backup a terminé correctement… Pendant son fonctionnement, je surveillais l’évolution du swap avec la commande htop… Le swap s’est chargé jusqu’à 500Mo… pas étonnent que ça plante… N’y aurait-il pas un petit bug à améliorer dans YunoHost à ce niveau-là ??
Hello,
J’ai exactement la même config,
Pour ma part j’ai contourné le problème en faisant un script qui exécute le backup sans data, puis un rsync des sauvegardes et des data par ssh vers un autre serveur où les données sont compressées.
Oui, faut pas se louper si tu sauvegardes toi-même les données à la mano… faut rien oublier!
Puis sur les droits des fichiers et répertoires pour rétablir la sauvegarde cela peut vite devenir compliqué!
Mais bon… pour ceux qui veulent mettre les mains dans le cambouis ça peut-être une méthode!
Ceci dit… ma méthode décrit plus haut, qui consiste à rajouter du swap, n’est pas très compliqué à mettre en œuvre!
Effectivement les sauvegardes trop volumineuses (notamment NextCloud) ne fonctionnent pas avec la console web. J’ai 1Go de swapp mais il semble que ça ne suffit pas. La console plante et on ne peut plus accéder à la liste des sauvegardes. Il faut supprimer le fichier de sauvegarde à moitié terminé (celui qui n’a pas de json associé) pour rétablir l’accès à la liste.
Du coup je fais à peu près la même chose que @Krakinou. Je sauvegarde tout en ligne de commande (cron) sauf les données de NextCloud (BACKUP_CORE_ONLY=1) qui pèsent 1 To, et j’envoie tout ça vers une seconde machine en rsync ssh. Le script garde les 10 dernières sauvegardes.
Pour les données de Nextcloud il s’agit essentiellement du répertoire /home/yunohost.app/nextcloud/data/. J’utilise aussi rsync ssh. J’ai testé la restauration, il faut appliquer les droits sur les fichiers et lancer un scan complet via occ. Exemple de restauration pour le répertoire multimédia:
Je n’ai pas utilisé Borg ou une autre solution toute prête. En lisant la documenation j’ai l’impression que ça n’apporte pas grand chose par rapport à mes quelques lignes de commande. Est-ce que quelqu’un saurait m’expliquer les avantages de ces solutions ?
Merci pour l’info…
Sauf qui pour moi c’est pas NextCloud qui occupe beaucoup de données… mais la messagerie… J’ai 10Go de messages archivés, sur mon YunoHost!
Donc, c’est peut-être un peu plus chiadé à sauvegarder manuellement!
La variable BACKUP_CORE_ONLY=1 fonctionne pour Yunohost mais pas seulement. Même si la documentation en ligne ne le précise pas clairement, elle fonctionne aussi pour les mails, pour les données utilisateurs, etc.
sudo BACKUP_CORE_ONLY=1 yunohost backup create --system
Warning: [WARN] /home/admin will not be saved, because 'BACKUP_CORE_ONLY' is set.
Warning: [WARN] /home/nextcloud will not be saved, because 'BACKUP_CORE_ONLY' is set.
Warning: [WARN] /home/gaston will not be saved, because 'BACKUP_CORE_ONLY' is set.
Warning: [WARN] /home/vmail will not be saved, because 'BACKUP_CORE_ONLY' is set.
Warning: [WARN] /home/wallabag2 will not be saved, because 'BACKUP_CORE_ONLY' is set.
Warning: [WARN] /var/mail will not be saved, because 'BACKUP_CORE_ONLY' is set.
Info: Now creating a backup archive from the files collected…
Success! Backup created
name: 20200106-214149
results:
apps:
system:
conf_cron: Success
conf_ldap: Success
conf_nginx: Success
conf_ssh: Success
conf_ssowat: Success
conf_xmpp: Success
conf_ynh_certs: Success
conf_ynh_currenthost: Success
conf_ynh_firewall: Success
conf_ynh_mysql: Success
data_home: Success
data_mail: Success
Ensuite tu peux sauvegarder /var/mail avec rsync par exemple. Je n’ai pas testé cette partie. Il faut vérifier que tu récupères bien test emails avec leurs propriétés. Restauration à tenter sur une vm ou autre machine de test
Dams… Tu sauvegardes que le cœur… après cela devient compliqué…
Il faut sauver les mails manuellement…
Il faut sauver Nextcloud manuellement…
Il faut sauver RoundCube (la configuration… les contacts) manuellement…
Le VPN… je sais pas s’il est sauvegardé…
Les autres petites logiciels… on sait pas…
Bref… c’est pas la solution de backup de rêve!
Parce qu’après, en plus il faut savoir remonter la sauvegarde, en cas de pépins!
@Dams, le très gros avantage de borg c’est qu’il gère les sauvegardes incrémentales. Du coup ça permet d’avoir un certain nombre de snapshot sans exploser la taille du backup puisque après le backup initial, seules les deltas viennent se rajouter au fur et à mesure. En fonction de la taille de ton espace de backup et de tes données, il est envisageable d’avoir une semaine, 1 mois ou plus de sauvegardes pour revenir en arrière si besoin.
Bonus complémentaire n°1: borg gère le chiffrement
Bonus complémentaire n°2: moi qui envoie mes backup chiffrés sur un cloud, une fois le 1er export réalisé les petits deltas de tous les jours sont uploadé en quelques dizaines de minutes malgré un débit de 1Mib/s en upload.
Avec une sauvegarde classique en rsync, ça serait inenvisageable.
