Comment structurer une politique de sauvegarde cohérente sur cinquante serveurs WordPress distincts, exploités par plusieurs équipes internes, sans dépendre d’une seule personne qui connaîtrait par cœur l’emplacement de chaque sauvegarde ? C’est la question qui a motivé ce comparatif entre Bareos et Restic, deux outils aux philosophies radicalement différentes.
Ce billet ne traite pas du choix du stockage de destination des sauvegardes, déjà couvert ailleurs indépendamment de l’outil utilisé pour les produire. Il se concentre exclusivement sur la comparaison entre centralisation et simplicité de restauration à l’échelle de ce parc précis.
Bareos : centralisation forte, complexité assumée
Bareos repose sur une architecture centralisée : un serveur de direction (le Director) pilote l’ensemble des travaux de sauvegarde, un catalogue en base de données conserve l’historique complet de chaque fichier sauvegardé sur chaque serveur, et des agents (les File Daemons) sont installés sur chacun des cinquante serveurs concernés.
Cette architecture permet une visibilité complète depuis un point unique : lister l’état de toutes les sauvegardes du parc, planifier centralement les fenêtres de sauvegarde, et restaurer un fichier précis sur un serveur donné sans jamais s’y connecter directement, via l’interface de commande du Director.
Restic : simplicité par serveur, sans point de contrôle unique
Restic fonctionne à l’inverse de façon totalement décentralisée : chaque serveur exécute sa propre commande de sauvegarde vers un dépôt chiffré, généralement un espace de stockage objet distant, sans dépendre d’un serveur central de coordination. Chaque dépôt est autonome, chiffré avec sa propre clé, et consultable indépendamment des autres.
# exécuté localement sur chacun des cinquante serveurs, via cron
restic backup /var/www /etc/nginx /etc/mysql \
--repo s3:https://stockage-objet.exemple.fr/sauvegardes-srv12 \
--exclude-file=/etc/restic/exclusions.txt
Comparatif sur les trois critères retenus
| Critère | Bareos | Restic |
|---|---|---|
| Centralisation | Forte : un catalogue unique pour tout le parc | Faible : un dépôt indépendant par serveur, sans vue globale native |
| Coût d’exploitation en temps | Élevé au démarrage (catalogue, Director, agents), plus léger ensuite | Faible au démarrage, mais supervision du parc à construire soi-même |
| Simplicité de restauration | Interface unique, restauration ciblée sans connexion directe au serveur | Restauration simple par serveur, mais recherche transversale absente nativement |
Le coût réel s’est révélé différent de l’estimation initiale
L’hypothèse de départ supposait que Restic, plus simple à déployer, coûterait moins cher en temps d’exploitation sur la durée. Ce n’est pas ce qu’a montré l’usage sur ce parc de cinquante serveurs : sans catalogue centralisé, l’équipe a dû construire elle-même un tableau de bord agrégeant l’état des cinquante dépôts Restic indépendants, un développement interne non anticipé au départ.
Bareos, à l’inverse, a demandé un effort de mise en place initial nettement plus lourd (installation du Director, configuration du catalogue en base de données, définition des jobs de sauvegarde pour chacun des cinquante serveurs), mais cet effort a été absorbé une seule fois, tandis que l’exploitation quotidienne s’est révélée ensuite plus légère, la visibilité centralisée évitant de reconstruire à la main ce que Bareos fournit nativement.
Ce que le choix dépend réellement de la taille de l’équipe
- Une petite équipe, sans personne dédiée à l’exploitation de l’infrastructure de sauvegarde, tire davantage bénéfice de la simplicité immédiate de Restic, quitte à accepter une visibilité transversale plus limitée.
- Une équipe disposant d’une personne capable de maintenir un Director Bareos dans la durée amortit rapidement l’effort de mise en place initial, grâce au temps gagné ensuite sur la supervision quotidienne du parc entier.
Le coût d’un outil de sauvegarde ne se mesure jamais uniquement à sa complexité de déploiement initiale ; il se mesure surtout au temps que l’équipe passera, chaque semaine, à vérifier que tout le parc est effectivement couvert.
Verdict pour ce parc de cinquante serveurs
Sur ce cas précis, Bareos a finalement été retenu, en raison de la taille du parc et de la présence, au sein de l’équipe, d’une personne disposée à en assurer l’exploitation dans la durée. Un parc de cinq ou dix serveurs, avec une équipe plus réduite, aurait probablement mieux tiré parti de la simplicité immédiate de Restic, quitte à accepter de perdre la vue centralisée qu’offre nativement Bareos.
Notre verdict
Il n’existe pas de réponse universelle entre ces deux outils : Bareos favorise la centralisation et la visibilité au prix d’un effort de mise en place initial conséquent, tandis que Restic favorise la simplicité immédiate au prix d’une visibilité transversale à construire soi-même. Le facteur décisif, sur ce parc de cinquante serveurs, a été la disponibilité d’une compétence interne capable d’assumer l’exploitation d’un Director sur la durée.
