Le Blog Utux

HTTP 200 GET /

Dans quel sens faut-il backuper ses serveurs ? Borg, backuppc

Rédigé par uTux 17 commentaires

Attention ceci n'est un comparatif entre backuppc et borg mais une courte réflexion. Je cherche à me débarrasser de backuppc pour les raisons suivantes:

  • Sous le capot c'est l'usine à gaz et c'est un enfer à installer surtout avec le webui quand votre distribution ne le propose pas ou pas complètement (genre FreeBSD).
  • Je n'aime pas du tout la planification des backup qu'on ne peut pas définir à des horaires (sauf avec des crons).
  • Il n'est pas disponible dans Nix alors que je migre vers NixOS (j'ai songé à le packager, mais cela me semble trop hardcore pour débuter).

Du coup j'examine les solutions alternatives de backup et tout le monde ne parle que de borg. Ce logiciel a l'air intéressant mais il semble plus adapté à la sauvegarde d'une machine individuelle qu'à l'utilisation dans un parc de centaines de serveurs. En effet les sauvegardes avec Borg se font en "push", il faut l'installer sur chaque serveur qui va ensuite pousser ses sauvegardes vers un repo distant. Avec Backuppc c'est du "pull", un unique serveur se charger d'aller chercher les données de vos serveurs distants.

Je pense que les deux solutions se défendent. L'avantage du pull (backuppc) c'est qu'on centralise la gestion, la surveillance et le stockage en un point, il n'y a rien à faire sur les serveurs. L'inconvénient est que votre serveur de sauvegarde doit disposer des accès root à l'intégralité de votre parc, ce qui peut constituer une faiblesse en terme de sécurité. Le push (Borg) est beaucoup plus sécurisé, par contre il faut l'installer et le gérer sur chaque machine ce qui ne doit pas être évident quand on en a des centaines.

La question est de savoir qui a raison. Faut-il faire ses sauvegardes en push et privilégier la sécurité ou en pull et privilégier la facilité de gestion ?

17 commentaires

#1  - Jean-dev a dit :

Déploiement de scénario logiciel:
Et pourquoi est-ce qu'on pourrait pas travailler sur 100 machines facilement ? À un moment j'avais fait une proposition de logiciel sur ubuntu :
http://forum.ubuntu-fr.org/viewtopic.php?id=2013871

On pourrait imaginer que borg rentre dans la catégorie de logiciels :)

Répondre
#2  - uTux a dit :

GLOIRE À ANSIBLE

Répondre
#3  - Giraya a dit :

Pour ma part j'ai choisi la méthode du pull, pour plus de sécurité au niveau des sauvegardes.
En effet, l'inconvénient du push c'est que si un serveur est compromis, la sauvegarde de celui-ci aussi.

Répondre
#4  - uTux a dit :

En effet je n'y avais pas pensé, le problème de sécurité se pose donc dans les deux sens.
Mais il me semble que la doc Borg a une solution pour ça, rendre l'édition/suppression des précédents backups impossible.

Répondre
#5  - jojolerigolo a dit :

Ta stratégie de sauvegarde est revoir en incluant le principe "two is one, one is none" pour t'éviter ce genre de mauvaise surprise et bien d'autres.

De toutes façons ce cas de figure n'impacte pas borg backup car il offre le versionnage et la déduplication, il suffit de restaurer le backup juste avant que la machine soit compromise et voilà!

Répondre
#6  - Giraya a dit :

Ma stratégie va très bien merci, ca fait 15 ans qu'elle tourne.
Chaque serveur sauvegardé a une rotation J+7, S+4, M+12 en déduplication.
Mon serveur de sauvegarde est lui même dupliqué sur un autre serveur indépendant (sur un datacenter différent).
Le serveur de sauvegarde principal n'a accès qu'en lecture sur les serveurs à sauvegarder, donc aucune altération possible des fichiers sur mes serveurs. Par ailleurs le serveur de sauvegarde est isolé et n'est accessible qu'après avoir montré patte blanche (IP+user/password).

Je ne parlais pas de la façon dont borg execute son processus de sauvegarde, mais de la méthode push en générale qui donne la plupart du temps accès à la sauvegarde en full access. Effectivement si borg fait du versionnage et que les anciennes versions ne sont accessibles qu'en lecture alors c'est bon aussi. Je vais regarder ca de plus près, j'avoue que j'ai vite survolé le site de borg.

Répondre
#7  - taziden a dit :

Bonjour,

À $travail, nous utilisons Borg pour les sauvegardes de presque 200 serveurs, dont certains assez volumineux et cela sans aucun problème. La déduplication fait merveille et couplée à Backupninja, c'est parfait [1].

Pour répondre à l'argument de la gestion compliquée avec une centaine de serveurs : ça n'est pas plus compliqué d'en gérer un ou 100, parce qu'à cette échelle-là, on industrialise et on utilise un outil comme Puppet, Chef, Salt ou Ansible pour gérer son parc.

[1] https://www.sysnove.fr/blog/2016/06/backupninja-borg.html

Répondre
#8  - Mike a dit :

Je choisis la méthode pull, c'est le serveur de backup qui va récupérer sa copie, et non pas l'inverse, aussi pour des raisons de sécurité.

Répondre
#9  - uTux a dit :

Le pull me parait beaucoup plus risqué car dans le cas où ton serveur de sauvegarde est compromis, l'attaquant peut alors se connecter en root@ssh sur l'intégralité des machines de ton parc. Si c'est en push, il ne peut que compromettre la machine sur laquelle il est, éventuellement son backup mais c'est tout.

Répondre
#10  - jojolerigolo a dit :

Peux tu développer ton modéle de menace et la strategie de sécurité que tu utilises ?

ça me parait étrange de choisir la méthode pull pour des raisons de sécurité.

Répondre
#11  - Nicolas K. a dit :

Tiens j'avais écrit un article sur l'installation de Borg : https://blog.karolak.fr/2017/05/05/35/

Pour ce qui est de l'installer sur une multitude de serveurs, ça se peut se faire avec Ansible. D'ailleurs comme le besoin va se poser bientôt pour moi, je pense que je vais écrire un rôle pour ça.

Répondre
#12  - uTux a dit :

J'y ai déjà pensé, étant membre d'un culte voué à Docker et Ansible.
Mais comment tu vérifie que tes backups se sont bien déroulé ? Tes 200 machines envoient un mail tous les jours ?

Répondre
#13  - PoluX a dit :

Pour info, borg en mode push c'est pas nécessairement openbar sur la machine de stockage : cf borg serve http://borgbackup.readthedocs.io/en/stable/usage/serve.html et l'option --append-only.

Répondre
#14  - mahikeulbody a dit :

Dans ce cas, le borg prune serait obligatoirement à faire sur la machine où il y a le backup, n'est-ce pas ?

Répondre
#15  - jojolehéros a dit :

J'ai fait le choix de borg il y a quelques temps en me basant sur d'autres critères et pour d'autres besoins.

J'ai choisi borg parce que
1) il fonctionne et il est stable
2) la documentation est disponible et compréhensible
3) il propose le chiffrement de manière sécurisée
4) il gère le versioning de manière simple
5) il offre la déduplication

J'ai des installations locales sur 3 machines et pour un parc de 2 machines, donc la problématique du push/pull ne me concerne pas pour l'instant. Le jour où ça se presente je ferai appel à l'ami du sysadmin: ansible.

Répondre
#16  - jojolehéros a dit :

Après mon passage à borgbackup, cette fois pour des besoins plutôt d'archivage que de sauvegarde, j'ai adopté lzip[1] qui se place dans le domaine de la compression sans perte performante ayant vocation à l'archivage à long terme. Il existe aussi la variante multi-thread plzip qui exploitera au mieux les machines multi-cores.

ça juste marche très bien, à voir dans 20 ans si il a tenu ses promesses de long terme.

[1]: http://www.nongnu.org/lzip/

Répondre
#17  - Simo a dit :

Bonjour,

Pour utiliser borg en mode pull j’ai utilisé la commande sshfs. Cette commande permet de monter un répertoire distant et je trouve cette solution assez pratique.
Je vous invite à découvrir cette commande pour ceux qui ne la connaissent pas.
Maintenant comme précisé plus haut push ou pull est une question de stratégie. Dans mon cas tout mes serveurs dialoguent sur un réseau local et seul la clef publique de borg est enregistrée sur tous mes serveurs(pour la connexion ssh). Cela me semble plus sécurisé que de laisser tous mes serveurs accéder à mon système de sauvegarde.
Cordialement.

Répondre

Écrire un commentaire

Quelle est le dernier caractère du mot b6tpj ?