Bonjour à tous, au cours des 5 dernières années chez ScalarX, nous avons eu l’occasion d’expérimenter différentes stratégies de backup de nos infrastructures de cloud ScalarCloud avec chacune leurs avantages et leurs inconvénients.
Actuellement la stratégie mise en place (nonobstant les clients disposant d’une infrastructure de backup dédiée sur-mesure) est la suivante :
1) Des sauvegardes des bases de données sont effectuées localement, puis sauvegardées ainsi que l’ensemble des fichiers présents sur le système, sur des serveurs de stockage dédiés à cet effet via rdiff-backup avec la fréquence et le niveau de rétention choisi par le client (par défaut 1 fois toutes les 24H00 sur 30 jours glissants)
2) Des backups incrémentaux sont effectués quotidiennement au niveau des hyperviseurs via Proxmox Backup Server
Il convient également de scinder dans cette analyse les deux principales typologies de clients : les clients disposant d’une solution redondée de type PRA, et ceux disposant d’un serveur simple.
Cette stratégie s’est révélée particulièrement efficace et répondant parfaitement aux besoins de sauvegarde jusqu’à présent.
Il y a cependant 2 remarques à faire :
1) Le passage des backups hyperviseurs vers PBS entraînent un effet de bord : si les backups sont en moyenne 10 fois plus rapides à s’exécuter qu’avant, le temps de restauration d’une machine complète s’en retrouve multiplié d’un facteur pouvant aller de 3 à 10 par rapport à l’ancien système utilisant vzdump.
2) Lorsqu’une demande de restauration fichiers ou base de données n’est pas la dernière sauvegarde disponible, le temps de restauration est là encore considérablement rallongée.
Dans la pratique, à ce jour, cela ne pose pas de soucis particulier : 90% des demandes concernent une restauration d’un petit ensemble de fichiers ou de répertoires depuis le dernier backup qui est directement accessible et les incidents nécessitant une restauration globale sont rares.
Cependant, nous avons de plus en plus de clients avec des profils impliquant des dizaines de millions de fichiers sur leurs sites et applications.
Comme vous le faisons régulièrement (2 fois par an en moyenne), nous avons mis cette stratégie à l’épreuve de plusieurs types d’incidents différents, allant d’une cryptobombe à retardement à la destruction d’un datacenter afin de déterminer le temps nécessaire à une reprise d’activité à grande échelle.
La conclusion est qu’en fonction de la nature et du périmètre de l’incident, ces temps de restauration, notamment de l’ensemble des machines intégrales en l’état peuvent être très (trop) longs à notre goût.
En conséquence nous travaillons actuellement sur 2 axes supplémentaires :
Une option pour les clients qui le souhaitent concernant les sauvegardes via rdiff-backup pour utiliser du stockage de production nvme et permettre des restaurations antérieures à la dernière sauvegarde grandement accélérées par rapport à aujourd’hui.
La réintégration des processus de backup via vzdump en sus des procédés de backup actuels afin de pallier à cette possibilité d’incident majeur mais rare, ce qui a pour conséquence d’augmenter la volumétrie de backup nécessaire par client.
Nous sommes entrain d’étudier les impacts commerciaux de telles mesures, mais il semblerait qu’il ne soit pas possible de les intégrer de manière transparente dans les offres actuelles, aussi seront-elles probablement (ce n’est pas encore arrêté, les études sont en cours) proposées de manière optionnelles.
Notez qu’il restera dans tous les cas toujours possible comme c’est le cas déjà pour une partie des clients de mettre en place des backups depuis et vers vos infrastructures / vos bureaux sans coût récurrent.
—
Christophe Casalegno
Vous pouvez me suivre sur : Twitter | Facebook | LinkedIn | Telegram | YouTube | Twitch
Laisser un commentaire