Sauvegardes chiffrées des conteneurs LXC sous Proxmox

Tech
1

Salut à tous et toutes !

Je suis en train d’optimiser le système de sauvegardes chez @Elukerio, car notre solution actuelle n’est pas assez performante.

Voici ce que l’on fait :

  • vzdump en mode suspend (meilleur rapport uptime/perf) pour les conteneurs.
  • les archives tar.lz0 sont sauvegardées avec borgbackup vers un support externe

Problème : Vzdump ne donne en sortie que des archives tar ce qui rend impossible la « déduplication » par borgbackup.

J’ai plusieurs pistes :

  • Utiliser le patch suivant https://ayufan.eu/projects/proxmox-ve-differential-backups/ permettant de faire des sauvegardes incrémentées avec vzdump, puis on chiffrera les archives (gpg ?) et on fera un rsync. Dans ce cas borgbackup est abandonné.
  • Faire en sorte d’avoir en sortie de vzdump des dossiers et non des archives, cela nécessite de patcher vzdump (il va falloir que je me mette au perl :confused: ), ensuite borgbackup fera le taf.

Qu’en pensez vous ? Avez-vous des pistes ? Est-ce que certain(e)s d’entre vous utilisent aussi borgbackup pour sauvegarder des conteneurs entiers ?

Merci d’avance pour vos retours :wink:

1 « J'aime »
2

J’ai opté pour l’usage de ZFS ce qui permet sous Proxmox:

  • la réplication entre noeuds du cluster et ouvre la porte aux migrations en quelques secondes ainsi qu’a la haute dispo
  • les backups sur snapshots (bien plus rapides)
  • un archivage distant de snapshots ce qui permet de bénéficier de la deduplication (et pas que pour les backups) et de la compression de ZFS et peut remplacer les backups

C’est une toute autre voie mais cela apporte beaucoup de confort d’administration.

3

J’ai appris il y a peu, les avantages de ZFS. Je pense qu’à terme, il faudra qu’on passe sur du ZFS.
L’idée était de trouver une solution qui fonctionne avec ce qu’on a sans avoir besoin de tout changer (les stockages des conteneurs sont en RAW et non en subvol).
Merci pour ce retour :+1:

4

Proxmox permet de migrer le stockage directement depuis raw à subvol ZFS depuis son interface web.
Ce n’est pas instantané et se fait en stoppant le container, mais c’est relativement simple à faire.

5

Encore faut-il avoir un système de fichiers ZFS.
En ce moment on a un RAID 6 avec mdadm (sur notre unique noeud proxmox), je me vois mal faire une transition à chaud pour remplacer mdadm par un RAIDZ2. C’est une opération kamikaze vu notre infra embryonnaire.

6

Oui, c’est sûr que dans ce cas la migration n’est pas triviale car mdadm n’est pas vraiment dynamique à ce niveau. Là aussi ZFS apporte du confort, on peut ajouter et depuis peu retirer des supports physiques (vdev) d’un pool en fonctionnement.

Pour ZFS, il faut aussi autant que possible avoir un accès direct aux disques, sans passer par une couche RAID hardware (si tu es en mdadm c’est que vous ne dépendez pas de RAID hardware, ce qui est déjà bien).

Dans les « bonus » de ZFS, j’ai oublié de mentionner les caches en lecture et écriture, qui permettent d’adjoindre au pool un ou plusieurs SSD pour accélérer les I/O. On peut même depuis peu indiquer que certains disques sont plus rapides (genre des 10 ou 15K voire SSD) pour que ZFS y conserve ce qui est le plus utile (les metadonnées par exemple).

7

Après cette digression très intéressante, je me permets de remettre le sujet des sauvegardes (vzdump+borg) sur la table.
Pensez-vous que modifier le comportement de vzdump afin qu’il sorte un dossier et non une archive soit une bonne idée ?

8

Voici ce que fait vzdump si le storage du container gère les snapshot:

  • il crée un snapshot
  • un fait unr archive tar du snapshot

Si le storage ne gère pas les snapshot, en mode suspend on a:

  • un premier rsync
  • un suspend du container
  • un second rsync
  • un resume du container
  • une archive tar de la copie faire par les rsync

Il suffirait peut-être de remplacer ce tar par un borgbackup mais ça oblige à modifier du code de proxmox et donc à chaque upgrade ça va pas être la joie.

Sinon, tu peux aussi bypasser tout le système de backup de proxmox et faire un mount du storage du container, lancer borgbackup pour le sauvegarder incrémentalement. Un petit script bash en cron doit faire le job.

1 « J'aime »
9

L’idée du montage temporaire a l’air pas mal du tout, en effet, pas besoin de craindre chaque mise à jour de Proxmox. Dans ce cas je pense qu’il serait intéressant d’utiliser le mode suspend, pour réduire le temps d’indisponibilité (comme vzdump d’ailleurs).
Je vais donc creuser cette piste, merci pour le conseil.

10

Tiens-nous au jus, ça nous intéresse aussi :wink:

11

zfs c’est 1Go de ram pour 1To de données …
sans moi :crazy_face:

12

backup sur snapshot un exemple concret stp, je suis assez curieux de voir les performances et avantages et inconvénients ?

13

un snapshot n’est pas une sauvegarde, même distant , je dois mal comprendre un truc ?

pour info je sauvegarde , j’ai bien dit sauvegarde, pas un cliché hein …, un container en 2 à 48 seconde sans downtime en techno hdd , plateau …(sauf ou j’ai un mysql ou postgresql , c’est 1 a 2 mn)
j’ai juste une sauvegarde de 200Go (sur une seule instance nextcloud) qui me gonfle et prends 55 mn : et faut que je regarde pourquoi , car elle est , elle aussi , en deduplication.

faites gaffes de pas vous faire chiffrer vos sauvegardes lors d’une attaque : croyez moi , ça fait très mal …

14

Non, pas besoin de 1Go de RAM pour 1To de données, il circule malheureusement beaucoup d’infos pas très fiables.

Le backup de snapshot permet d’avoir une image cohérence à un instant donné du filesystem qu’on sauvegarde. Le snapshot le fige, on fait le backup du snapshot pendant que le filesystem continue à être modifié au delà du snapshot.
Ce n’est pas spécifique à ZFS, on peut faire pareil avec ext4 et lvm.
Oui, les snapshot ne sont pas des backups, car ils ne créent pas de copie des données (pour ça aussi qu’ils sont instantanés).
Ils permettent par contre de revenir en arrière, ce qui est bien pratique quand ce n’est pas le stockage physique qui est en faute, mais une opération logique… comme la suppression ou l’écrasement de données par une fausse manip, un bug, voire un cryptolocker :wink:

Sauvegarde vs snapshots

Je suis d’accord qu’un snapshot local n’est pas une sauvegarde. Une sauvegarde c’est une copie sur un support différent et on n’a pas de copie des données sur un support différent avec un snapshot local.

Par contre, une copie distante de snapshot est une façon de faire une sauvegarde, car on a bien une copie des données sur un support différent.

L’avantage des snapshot sur ZFS c’est son côté différentiel qui fait qu’on ne recopie que ce qui a changé, non pas en parcourant le filesystem pour détecter les changements sur les fichiers (et avec donc plein d’I/O à la clé et de la pollution de cache), mais en transmettant directement les blocs de données où des changements ont été faits depuis le précedent snapshot car ZFS en maintient naturellement la liste pour son fonctionnement copy-on-write (btrfs aussi).

Sur un cluster proxmox, c’est comme ça que fonctionne la « replication ». Une copie initiale d’un premier snapshot, puis des snapshot différentiels, avec à l’autre bout un filesystem identique, immédiatement utilisable (pas besoin de passer par une restauration).

Je n’essaye pas de « vendre » du ZFS, juste d’un peu mieux le faire connaître, de partager l’expérience acquise en l’utilisant.

Il regroupe ce qu’on fait péniblement avec ext4 + lvm + mdadm + bcache et même luks depuis la 0.8.0.
Pour la dédup et la compression je ne vois même pas comment faire proprement sur de l’ext4.

Après chacun fait comme il veut et choisit ses outils, mais il est bon de savoir que ZFS fait pour le mettre dans liste des choix possibles.

15

Faudrait qu’on papote en direct , c’est lourd avec un clavier :wink:
En fait je pense que l’on ne se représente pas le snapshot de la même manière tous les deux !!!
A part pour du test pré-mise en prod … je ne fais pas de snapshot (et encore parfois cela te pète à la tronche quand les technos sous-jacentes ne supportent pas les snapshots).
Pis si ton système de libération des snapshot merde … ben tu satures tout : ca j’aime pas du tout.
Ou lorsque tu as bcp d’entrée sortie durant le snapshot quand tu dois resynchroniser … ca claque pas mal aussi.

C’est pour cela que je suis curieux (réellement!) de voir une prod avec le snapshot utilisée pour la sauvegarde.
Je sais que veeam backup le fait ou je bosse … mais on a déjà eu des retours arrières bien tordus, et personne ne fut capable de dire pourquoi !.
Mais je vais sérieusement regardé ZFS et les snapshots sous Proxmox.

Ensuite perso, ZFS ne me conviendrait pas pour ilinux car je me sert d’un système de fichier distribué … donc pas besoin de bascule ou snapshot : le disque dur est réseau (ceph/rdb) donc visible par tout mes noeuds , juste les changements de contexte cpu, pile, memoire etc à basculer. Pas de disque.

16

Le snapshot (LVM, ZFS, VIRT, LXD/LXC et bien d’autres) est une technique pour « FIGER » l’état d’une VM, d’un container, d’un volume ou d’un storage… Pour cela il stock le différentiel (objet figé / objet en ligne) soit en RAM soit dans un espace disque dédié.
Ce qui te permet :

  • de faire un BACKUP de l’objet figé
  • de garder une image saine avant d’essayer une installation ou une configuration qui risque d’exploser l’objet

Une fois l’objet Sauvegardé, on supprime le snapshot (le système réintègre le différentiel dans l’objet figé) et c’est comme s’il n’y avait rien eu.
Si tu as explosé ton container car tes modifs n’ont pas fonctionné : Tu reviens au snapshot, et tes modifications ont disparu (la VM est « revenu dans le passé » en quelque sorte).

17

Oui les snapshots consomment de l’espace de stockage, mais pas plus qu’un backup incrémental… donc oui, on peut saturer dans les deux cas si on ne gère pas ça correctement (comme presque tout, non ?).

Comme @djayroma le rappelle, un snapshot c’est juste un moyen de figer l’état d’un filesystem.

Avec ZFS (et btrfs), les snapshots sont au coeur de leur fonctionnement copy-on-write, donc si ça pête c’est que tout ZFS ou btrfs est inutilisable.
La possibilité qu’ils offrent de calculer des différentiels entre snapshot et de les transmettre à une machine distante, permet de les coupler à une stratégie de backup voire de la faire reposer dessus.

Comme c’est très rapide, que les volumes à prendre en compte à chaque synchro sont dépendants uniquement des changements et pas de l’ensemble des données stockées, ça permet de faire de la réplication fréquente sans être dans du temps réel comme ceph (que j’ai aussi utilisé) en s’accommodant très bien de volumes stockés importants.

En plus des snapshot (read-only) il y a les clones (read-write)… qui sont comme des fork de filesystem et ça pour tester un truc sans stopper le filesystem en prod c’est d’un très grand confort.

18

bon pour les snapshot, on va pas en parler des heures je crois qu’on connaît tous le truc. Les rappels sont toujours bien pour ceux qui nous lisent.:stuck_out_tongue_winking_eye: (vous avez oublié les VSS de MS …bahhhhhhh)
Moi ce que je comprends pas c’est comment vous faites avaler votre snapshot dans votre logiciel (?) de backup le tout en deduplication …

(qts : quel est le rapport RAM bouffée / Go hébergés pour ZFS ? vu que je semble plus trop à jour … à l’époque je faisais péniblement du Nexenta, opensolaris, freenas)

https://www.freenas.org/images/newsletter/assets/FreeNAS_Hardware_Requirements.pdf

19

oui mais fait ainsi si tu as des bases c’est crade.
tu as des transactions par forcément commité.
et je parle que de bases de données
plein d’autres type d’appli peuvent demander un Sync.
moi je fais pas comme ca.
je posterai mon script de backup sur le wiki ilinux quand j’aurais un peu de temps, et il est très très simple.
Rappel :
doc. proxmox

snapshot mode

This mode provides the lowest operation downtcime, at the cost of a small inconstancy risk.

20

en quoi zfs te permet des bascules rapides ?
ou alors ton pool zfs est sur un san fibré ?
mais je ne penses pas que zfs soit un système de fichier distribué …
perso je suis sur ceph rdb et là oui mon pool ceph , qui est partagé sur tout les noeuds du cluster , est visible et dispo pour Toutes les vm et lxc au même moment : donc migration quasi temps réelle.

l’archi. de sauvegarde que j’utilise est totalement invisible de la prod. car elle a son réseau dédié, donc bcp plus difficilement attaquable.
https://wiki.ilinux.fr/doku.php?id=documentations:reseau
second point elle est totalement indépendante de la techno utilisée : vm, lxc, machine physique : c’est irrécupérable … le grand saut quoi :scream:
Ceux qui s’amusent à pousser les sauvegardes depuis la prod. vers du stockage courent le gros risque d’une attaque par chiffrement des backup.
Donc pour l’instant : les snapshot pour les tests oui, la sauvegarde non. Je n’ai pas encore assez de volumetrie changeante massivement pour envisager leur utilisation pour palier des downtime problématique.
De toute façon ceph permet ce genre de truc, et je ne suis pas là avec mes 50 utilisateurs …