Sauvegardes chiffrées des conteneurs LXC sous Proxmox

#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 Like
#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 Like
#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.