===== Sauvegardes des machines virtuelles =====

==== Fonctionnement ====

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

<code bash>
zfs list -t snapshot
</code>

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ées** -> **Sauvegarde**. Les archives crées sont stockées dans ''/raidZ/backup'' sur Charybde et visibles dans l'interface de Proxmox VE.

<WRAP center round important 90%>
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.
</WRAP>

===== 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 :

<code>
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

</code>

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
<code>
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
</code>
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 :
  - On garde tous les snapshots de moins de 15 jours
  - Un snapshot par jour entre 15 jours et 1 mois
  - Un snapshot tous les deux jours entre 1 mois et deux mois
  - Un snapshot par semaine entre 2 mois et 6 mois
  - 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 : 
  * Ne pas garder les logs plus d'un an.
  * Pouvoir les ressortir quoi qu'il arrive pendant un an.

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 :
  * Conserver qu'un seul snapshot de backup
  * Envoyer les incréments : il serait bien con de surcharger notre réseau.

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