===== 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ées** -> **Sauvegarde**. 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/** ou **/volumes/disks/images/** 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 : - 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 ...