Table des matières

Sauvegardes des machines virtuelles

Fonctionnement

Des snapshots sont effectués sur les datasets critiques toutes les 6 heures. On peut les voir avec un :

zfs list -t snapshot

Les incréments des snapshots réalisés sont ensuite envoyé sur le dataset de sauvegarde (avec le suffixe _back) correspondant. Ceci est possible grâce au script /root/scriptSync.py.

Pour les machines non stockées sur les NAS (un vpn par sécurité et les bases de données pour des raisons de performance), un backup est effectué régulièrement par Proxmox VE. La configuration de ces sauvegardes se fait dans Centre de donnéesSauvegarde. Les archives crées sont stockées dans /raidZ/backup sur Charybde et visibles dans l'interface de Proxmox VE.

Il n'y a pas de sauvegarde automatiques sur les serveurs hors cluster. Néanmoins, les disques du parefeu sont (normalement tous) en RAID-1. Aucune de sauvegarde des serveurs télé actuellement.

Restauration de VM

Cas d'un VM sauvegardée par Proxmox VE

Les backups présents sur Charybde sont restaurables directement depuis l'interface Web.

Cas d'une VM stockée sur le NAS

Les sauvegardes des VMs sont, pour les openvz, sur :

  /raidZ/dataset/.zfs/snapshot/private

Et pour les kvms, sur :

  /volumes/raidZ/dataset/.zfs/snapshot/images

Les dossiers que vous voyez sont au format année mois jour heure…

Vous trouverez la racine de votre VM dans le sous dossier /volumes/disks/private/<id> ou /volumes/disks/images/<id>

Pour rétablir une VM stockée sur le NAS, il vous suffit de copier la sauvegarde dans le dossier de la VM, en aillant bien pensé à éteindre la Vm sous proxmox… Par exemple pour restaurer la Vm 108 :

Sous proxmox:

vzctl stop 108

Sur le NAS

mv /raidZ/dataset/private/{108,108old}

cp -pr /raidZ/dataset/.zfs/snapshot/201309131700/private/108/* /raidZ/dataset/private/108/

Puis sous proxmox:

vzctl start 108

Si le snapshot n'est disponible plus que sur l'autre NAS, alors utilisez simplement un scp. Par exemple pour restaurer la vm 130 qui est sur scylla mais dont le backup est sur charybde

On se connecte en root sur charybde, puis 
scp /raidZ/scylla_prod_back/.zfs/snapshot/201502251515/images/130/vm-130-disk-1.qcow2 
 root@192.168.102.147:/raidZ/scylla_prod/images/130/vm-130-disk-1.qcow2

Et voilà :p

Et les bases de données?

Il serait en effet dommage de perdre nos précieuses informations, d'autant plus qu'on ne peut, de par leur extrême régularité et leur légendaire assiduité, compter sur les backups manuel des Vms locales. Chaque jour, un dump de la base de donnée est faite sur un point de montage NFS, qui correspond sur Scylla à /raidZ/backup_sql. Pour remonter dans l'historique, il suffit de s'aventurer dans les snapshots, qui sont synchronisés sur Charybde.

Le ménage?

Le ménage est fait sur les datasets de sauvegarde tous les jours :

  1. On garde tous les snapshots de moins de 15 jours
  2. Un snapshot par jour entre 15 jours et 1 mois
  3. Un snapshot tous les deux jours entre 1 mois et deux mois
  4. Un snapshot par semaine entre 2 mois et 6 mois
  5. Un snapshot par mois ensuite.

Vous trouverez les scripts de synchronisation/sauvegarde et de nettoyage sur le gitlab MiNET.

Cas particulier : la sauvegarde des logs proxys

Pour des raisons de praticité et d'espace occupé, nous ne stockons pas de manière durable nos logs proxy sur la machine elle même mais sur un share NFS sur un de nos NAS.

Les logs uploadés via NFS sont chiffrés avec une clé GPG.

Étant donné la législation actuelle, nous sommes tenus de :

Nous sommes donc dans l'obligation de faire des snapshots de nos datasets de log proxys, et d'envoyer le tout sur l'autres NAS. Néanmoins, le script classique ne convient pas car il journalise. Le script a donc été modifié en svg_log.py afin de :

Le script svg_log.py est disponible sur le gitlab MiNET …