Le Blog Utux

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 :)

GLOIRE À ANSIBLE

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.

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.

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à!

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.

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

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é.

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.

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é.

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.

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 ?

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.

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

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.

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/

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.