Un cabinet d’expertise comptable m’appelle un lundi : leur prestataire VMware a triplé le devis de renouvellement, Veeam compris, et ils veulent savoir ce qu’ils perdent en partant. La crainte n’était pas l’hyperviseur, qu’ils maîtrisaient mal de toute façon. C’était Veeam. Quinze ans d’habitudes, des restaurations de fichiers à la demande pour les utilisateurs, un plan de reprise écrit autour de cet outil. Personne ne quitte ça de gaieté de cœur.
La première chose que je leur ai expliquée, c’est qu’il n’y a pas de produit unique en face. Veeam concentrait dans une licence ce que l’écosystème Proxmox distribue sur trois briques, et c’est plutôt une bonne nouvelle une fois qu’on a fait le deuil de l’interface unique.
Remplacer Veeam sous Proxmox, c’est répartir son rôle sur trois briques : Proxmox Backup Server pour la sauvegarde incrémentale dédupliquée et la restauration de fichiers, les snapshots ZFS pour les retours arrière instantanés, la réplication pour la reprise après sinistre.
Proxmox Backup Server reprend le cœur du métier : des sauvegardes incrémentales et dédupliquées, chiffrées, avec rétention configurable et vérification d’intégrité, jusqu’à la restauration granulaire de fichiers sans avoir à remonter la machine entière. C’est là que les réflexes reviennent le plus vite, en quelques jours. La déduplication m’avait surpris la première fois que je l’ai mesurée : sur une vingtaine de VM Linux assez proches, le ratio dépasse facilement 10:1, parce que les blocs communs d’une machine à l’autre ne sont stockés qu’une seule fois.
Les retours arrière instantanés, eux, ne viennent plus d’un snapshot d’hyperviseur mais de ZFS, et le confort y gagne. Un snapshot se prend dans l’instant et ne pèse presque rien tant que les données ne divergent pas. Avant une montée de version qui sent le roussi, je fige l’état ; si la mise à jour tourne mal, le retour prend quelques secondes. Une limite à ne jamais oublier, en revanche : ce snapshot vit sur le même stockage que la VM, donc il ne protège d’aucune panne disque. C’est un filet pour les bêtises, pas pour les sinistres. Pour le sinistre, justement, il y a la réplication ZFS, qui recopie vos VM vers un autre nœud ou un autre site à intervalle régulier. Quand un nœud tombe, la copie redémarre ailleurs sans attendre une restauration complète. Couplez-la à une synchronisation PBS vers un second site et le plan de reprise tient debout. Reste à regarder le RPO en face — la quantité de données que vous acceptez de perdre entre deux copies : répliquer toutes les quinze minutes, c’est accepter d’en perdre quinze le jour venu. Ce chiffre se décide à froid, autour d’une table, pas dans la panique.
Le vrai point de vigilance est ailleurs, et c’est celui que je n’expédie jamais. Veeam savait dialoguer avec certaines applications pour garantir une sauvegarde transactionnellement cohérente. Une base de données figée à chaud sans précaution peut se restaurer dans un état inexploitable, et vous ne le découvrirez qu’en essayant de la remonter, c’est-à-dire au plus mauvais moment. Selon ce que vous hébergez, il faut donc orchestrer une mise au repos avant le snapshot : un hook met l’application en pause le temps de figer l’état, puis la relâche. PBS sait déclencher ces hooks. Encore faut-il les écrire, et surtout les rejouer pour de vrai au moins une fois par type d’application. Aucun produit ne garantit cette cohérence à votre place. Elle se vérifie, restauration à l’appui, ou elle n’existe pas.
Pour le cabinet comptable, l’histoire s’est bien finie, à une frayeur près. Trois semaines après la bascule, leur base de paie a dû être restaurée suite à une fausse manipulation interne. Sans le hook de mise au repos qu’on avait écrit et testé ensemble le mois précédent, la restauration aurait ramené une base corrompue, en pleine période de bulletins. Elle est remontée propre en vingt minutes. C’est exactement ce jour-là, et pas avant, qu’ils ont vraiment quitté Veeam.