je ne backup avec vzdump.
mais avec BorgBackup, sorry.
tu fais du zfs avec 2 x 2to ?
yes mais je ne suis pas très content de la perf chez OVH notamment avec les backup qui sont longs et génèrent beaucoup d’IO
Pourtant tu les paies bien … 100€ par mois 
J’ai tout viré de chez eux, ils prennent les petits pour des poires … et comme je n’en suis pas une : j’auto-héberge tout sur 2 liens VDSL.
Tu peux aller voir ma conf. ca marche bien promox avec ceph.
il faut juste choisir les bons ingrédient set appliquer la bonne recette … enfin pour l’instant j’en suis content.
Auto hébergement bien joué! mais trop compliqué pour moi je commence à regarder les offres cloud pour ma migration reste à trouver le bon compromis !
Salut à toutes et à tous,
j’ai fait pas mal de recherches ces derniers jours à propos des méthodes de backup au sein de proxmox, afin de faire un script capable de sauvegarder les conteneurs avec borg en profitant à fond de la déduplication.
L’idée de @cquest m’a mis sur la bonne voie :
Le script que j’ai fait fonctionne plutôt bien, il est capable de gérer à la fois les subvols et le volumes raw, c’est pile poil ce qui me fallait.
Cependant je suis confronté à un dernier problème de taille ! Les conteneurs LXC sont en mode « unprivileged », les uid/gid des fichiers du conteneur ont donc une valeur élevée (>100000). Or cela pose problème à borg, en dépit il réinitialise toutes les valeurs à 0:0. Ainsi quand le conteneur sera restauré depuis une archive borg, tous ses fichiers appartiendront à root !
Pour pallier au problème, j’ai pour l’instant trouvé une bidouille, consistant à recopier (avant de lancer borg) tous les fichiers dans un dossier /nimporte depuis le point de montage temporaire, puis éxecuter :
for file in $(find /nimporte); do chown $(($(stat $file -c%u) - 100000)):$(($(stat $file -c%g) - 100000)) $file; done
Cette technique marche mais elle est très peu performante.
J’ai donc entrepris l’étude du code de vzdump car dans les .tar qu’il fabrique, les uid/gid commencent à 0:0, ce qui rend ces archives « restorables » sous forme de conteneur privilégié ou non (on a le choix), le tout dans un délai imperceptible. Malheureusement, après la lecture complète du VZdump.pm et de ses dépendances je ne sais toujours pas comment il fait cette modification sur les fichiers.
Je n’ai rien trouvé d’intéressant sur le web à ce sujet … Avez-vous une idée, des pistes à me suggérer ?
Merci d’avance <3
2 « J'aime »
Non mais je suis intéressé par la réponse.
pour les histoires de uid et gid le gars de borgbackup fait ainsi pour bien préserver cette notion :
https://github.com/borgbackup/borg/blob/master/docs/deployment/pull-backup.rst
c’est ce que tu souhaites ? (pour mon archi. c’est pile poil ce que je dois faire pour un full backup, ce que je ne fais pas encore)
Après je vous cache pas que c’est … pas des trucs triviaux. On est dans la grosse cuisine.
j’ai vu ça aussi … borg export-tar
question : pourquoi tu tapes pas direct dans ça ? direct le snapshot avec un montage de ce dernier en readonly ?
Ça y est j’ai trouvé mon erreur ! C’était tout bête, j’ai été induit en erreur par plusieurs issues ouvertes où les problèmes présentés était semblables au mien 
(https://github.com/borgbackup/borg/issues e.g. #1869 #1751).
Mon soucis venait du fait que j’avais mal compris l’option --numeric-owner en effet si elle est utilisée lors de la création d’une archive elle ne sert qu’à garder les permissions des fichiers.
J’ai appris ensuite que lors de l’extraction d’une archive, Borg ne retranscrit pas directement l’uid des fichiers, il va d’abord vérifier que chaque uid correspond à un utilisateur existant sur le système. D’après ce que j’ai compris, s’il remarque que l’uid du propriétaire d’un fichier n’existe pas sur le système alors il le remplace par celui de l’utilisateur qui a lancé Borg.
Par conséquent l’option qui convient pour garder les uid intactes lors de l’extraction est --numeric-owner ! e.g. borg extract --numeric-owner ssh://user@backup-server.eluker.io::pct1000-2019-11-09T23:13:57
Bref c’était bien plus facile que prévu, merci @anon6747921 pour l’idée du backup en mode pull, je vais peut-être choisir cette méthode.
Désolé d’avoir fait perdre du temps à ceux qui ont cherché à résoudre mon problème.
… salut mablr.
Je dois refaire mon code de backup en vue d’atteindre l’objectif de faire un backup qui permette de restorer le conteneur entier (tout son file system AVEC les bonnes permissions etc) : j’ai du taf !
Car j’avais pas percuté le coup des uid/gid, car je sauvegarde /etc /root /var /home , donc les données et fichiers stratégiques. Donc je peux repartir from scratch mais c’est long.
D’ou l’idée de faire un snapshot et donc pouvoir bosser peinard (offline pendant la prod. sans interruption de service) sur un montage local à l’hyperviseur.
je dois remettre le couvert pour rajouter une méthode de backup pour borg. (j’ai juste eu à restaurer quelques fic. de conf et une instance nextcloud pour tester ma solution)
Edit : donc tu confirmes que borg stocke bien les info uid/gid lors du backup ?
(tout se jouerait à la restauration : --numeric-owner)
Ça tombe bien c’est à peu de choses près ce que je suis en train de faire. Je vais publier le script que j’aurai bientôt fini et documenté, comme ça, je ferai gagner du temps à quelques personnes !
D’après mes tests : oui !
t’es un chef !
j’ai la tête sous l’eau niveau taf. j’vais pas pouvoir avancer en // , sorry.
a++
La même chose de mon côté (en prépa) 
Mais j’essaye de sortir ça au plus vite
1 « J'aime »
je suis aussi tombé sur ça …
https://github.com/borgbackup/borg/blob/master/docs/deployment/pull-backup.rst
Salut @mablr on a un peu le même problème à la FELINN. Voici rapidement mes étapes de réfléxion sur les backups chiffrés avec proxmox.
Quelques postulats qui me paraissent importants:
- profiter des capacités de LVM pour faire un dump et de l’integration de vzdump
- ne pas utiliser de stockage temporaire sur les disques (on the fly)
- compression avant d’envoyer les backups
- utiliser la dé-duplication
- chiffrer les backups
- faire les sauvegardes en
pullpour la sécurité (merci @cquest)
1. utiliser borg avec les fichiers tar
# backup
vzdump --stdout ... | borg backup ...
# restore
borg export-tar ... | pct restore ...
borg déduplique très mal les fichiers tar
2. utiliser borg --chunker-params avec les fichiers tar
Après quelques recherches sur ces fameux chunks et notament ce thread j’avais espoir d’arriver à faire de la dé-duplication au moins un peu correct.
# backup
vzdump --stdout ... | borg backup --chunker-params 12,20,16,4095 ...
J’arrive à gagner jusqu’à 1/3 de dé-duplication en ajustant bien mais pas plus
c’est pas assez.
3. utiliser borg avec cpio
extraire l’archive avant de la donner à borg.
# backup
vzdump --stdout ... | cpio -i -H tar --to-stdout | borg backup ...
# restore
borg extract --stdout ... stdin | cpio -o -H tar | pct restore ...
bonne dé-duplication
impossible de récupérer les données depuis le stream du fichier stdin Cf. doc, au mieux borg peut extraire les fichiers dans le dossier courant.
4. utiliser zbackup
Finalement zabckup fonctionne bien. C’est la meilleure option que j’ai jusque-là.
pas de dev depuis 4 ans, mais c’est toujours stable et dans les depos.
# backup
vzdump ... --stdout | zbackup backup...
# restore
zbackup restore ... | pct restore ...
utilise vzdump
bonne déduplication
chiffré et compréssé
tout est on the fly avec |
pas de facilité pour l’envoi sur le serveur 
sshfs
pas de rolling/prune script, j’ai commencé un script python pour faire tout ça mais finalement on va passer à :
5. utiliser ZFS
Finalement on va changer le controlleur RAID pour pouvoir utiliser ZFS (le controlleur actuel ne permet pas de faire du pass-through, on est obligé d’avoir un RAID materiel).
profiter des capacités de LVM pour faire un dump et de l’integration de vzdump ZFS, intégré dans PVE pve-sync
ne pas utiliser de stockage temporaire sur les disques (on the fly) zfs permet d’envoyer directement avec ssh.
compression avant d’envoyer les backups SSH peut faire ça ou | lzo
utiliser la dé-duplication sans utiliser la dé-duplication intégrée dans ZFS, avec les snapshots incrémental distants c’est assez similaire au final.
chiffrer les backups ZFS support nativement le chiffrement, pour envoyer/recevoir les backups également
Comme l’explique bien @cquest c’est une autre manière de voir les backups. Je trouve ça vraiment beaucoup plus pratique. Je vais pas refaire toute la liste mais ZFS pour nous beaucoup d’avantages et est très bien intégré à proxmox.
NB: borg sera bientôt capable de prendre des archives en entrée avec la fonction import-tar (milestone 49).
Oui mais …
ZFS c’est un file system pas un système de fichier distribué : donc pas jouable sur un cluster, il faut un max de puissance pour ZFS. Vous avez vu les serveurs et les sous-systèmes disque de cquest ? … moi j’ai juste pas le sou.
Je suis en basse conso à tout les étages.
==> je vais , quant j’aurai du temps de cerveau dispo., paufiner borg avec SSHFs et surtout bosser à partie d’un snapshot RBD (Ceph inside).
Ceph c’est vraiment un autre monde les gars … on parle plus de RAID bazar, là …
Avec du pseudo RAID quand un disque péte , c’est la course pour changer le disque HS : on ne connaît pas ça sous Ceph … on a plus de temps , c’est l’espace libre qui peut nous tuer , pas le reste .
Si vos hyperviseurs prennent une attaque … que se passe-t-il pour vos sauvegardes ? (toutes accessibles depuis… vos hyperviseurs)
Pour ZFS… méfiez vous de la déduplication. Au final, on y gagne pas tant que ça et ça bouffe de la RAM.
Pour la compression, pas besoin de SSH ou autre, il vaut mieux toujours l’utiliser sous ZFS et activer lz4 pas défaut sur le pool.
Autre point non abordé… le push vs pull (question de sécurité).
Une synchro de snapshots ZFS peut se faire en pull: le serveur de backup vient se connecter en SSH au serveur à backuper et récupère le diff de snapshots.
Comme on vient compléter ce qu’on a déjà copié, même si l’original a été compromis, on ne revient pas en arrière et seuls les nouveaux snapshots peuvent être vérolés si je ne me trompe pas.
Pour le disque HS… c’est uniquement une question de niveau de redondance. Plus il est faible, plus il est urgent de remplacer le disque, mais quand il est élevé, si la ceinture lâche on a encore les bretelles
Donc RAIDZ est le plus bas niveau, ensuite on a RAIDZ2 (mon choix sur 8 disques) et RAIDZ3, voire MIRROR.
Sur un pool ZFS on peut de plus avoir un disque en spare, qui sera utilisé automatiquement pour remplacer un disque jugé HS (trop d’erreurs). zed nous informera par mail du problème…
@cquest, merci pour tes remarques, je vais rééditer mon post.
Pour ZFS… méfiez vous de la déduplication. Au final, on y gagne pas tant que ça et ça bouffe de la RAM.
Oui, je me suis pas bien exprimé je pensais pas à la déduplication native ZFS qui est assez décevante d’après ce que j’ai lu. Je parlais d’utiliser des sauvegardes incrémentales de snapshots distantes, ce n’est pas de la dé-duplication mais comme on évite la redondance des blocks la finalité est proche de la dé-duplication.
Autre point non abordé… le push vs pull (question de sécurité).
Effctivement, pull parait le plus sûre dans le cas où le serveur de prod à plus de chance de se faire hacker.
Pour le disque HS… c’est uniquement une question de niveau de redondance.
On va faire un RAIDZ2 (RAID 6) avec 1 disque spare. Comme on sera prévenu par mail/SMS si un problème surgit on sera sur le pont rapidement avec les disques de rechange.
@anon6747921 merci pour ton retour, je comprend tes réticences.
ZFS c’est un file system pas un système de fichier distribué : donc pas jouable sur un cluster
Effectivement c’est très différant. pve-sync permet de faire une bonne synchronisation entre les serveurs, ce n’est PAS distribué mais pour la réplication c’est sympa.
il faut un max de puissance pour ZFS.
Il semble que par défaut ARC utilise un maximum de RAM et ça permet d’optimiser les accès disque, donc l’usure, donc le renouvellement des disques. C’est possible de paramétrer le cache en RAM (ARC), il faut faire des tests pour vraiment voir la différence de performance. Dans tous les cas il en faut pas mal et ça coûte chère. Nous ça nous convient bien on a récupérer à prix dérisoire 96Go ECC.
Je suis en basse conso à tout les étages
Ce serait intéressant de comparer l’efficience énergétique des méthode de sauvegarde. La RAM ça consomme pas beaucoup relativement au proc, il faudrait d’estimer la complexité de l’algo de dé-duplication utilisé par borg et de comparer celle d’un snapshot. C’est pas évidant à faire… je serais vraiment curieux du résultat.
Avec du pseudo RAID quand un disque péte , c’est la course pour changer le disque HS
RAIDZ2 C’est un RAID 6 logiciel il me semble, pourquoi « pseudo » ? Avec un disque spare ça permet que trois disques crament avant de perdre des données (sans le backup). Ça arrive mais c’est peu probable. On a 7 disques en RAID 6 (sans compter le spare) ça fait: 0.0000015832069366 sur une année en étant pessimiste, d’après ce site (ils ne publient l’algo de calcul donc ça vaut ce que ça vaut).
Si vos hyperviseurs prennent une attaque … que se passe-t-il pour vos sauvegardes ? (toutes accessibles depuis… vos hyperviseurs)
Toutes les sauvegardes ne sont pas accessibles depuis tous les serveurs (pull).
Si tous les serveurs sont compromis effectivement c’est problématique. Je connais pas bien Ceph mais c’est la même chose si tous les nodes sont compromis, non ?
Ah ok, si tu vois les snapshots comme une forme de déduplication, oui ,c’est nickel et très efficace en stockage.
Pour la redondance, j’ai 2 vdev de 8 disques en RAIDZ2 + 1 disque en spare qui peut aller remplacer n’importe lequel des 16 disques qui aurait un problème.
Je fais aussi un scrub régulier (4 heures chaque nuit en heure creuse) pour vérifier la cohérence des données.
Pour l’ARC, comme le serveur de stockage ne fait que ça, je lui laisse la RAM, et j’ai du SSD en L2ARC. Dommage par contre, que ces caches ne soient pas persistants en cas de reboot, mais bon, c’est rare les reboot
Pour ceph, si l’un des noeuds est compromis, le stockage distribué l’est aussi à ce qu’il me semble vu que ce noeud peut écrire ce qu’il veut sur le cluster, non ?
Ce que j’envisage aussi, c’est une réplique distante avec un serveur qui ne s’allume que de temps en temps pour le temps du backup. Bénef énergétique et sécurité (un machine éteinte est difficile à compromettre).