Sauvegarde: push or pull ?

Support Debian
#1

Bonsoir à tous,
je poste dans ce forum , mais ça aurait aussi pu être dans pause café.
Pour sauvegarder un petit parc composé principalement de debian et 1 windows, quelle stratégie de sauvegarde sur un NAS vaut il mieux utiliser:

avantage/inconvénient de chaque méthode ? Le troll/débat est ouvert !
Le résultat pourra servir pour créer une page wiki générale consacrée à la sauvegarde.

nota: ce sujet est souvent abordé sur le net, mais c’est votre avis/expérience de debianistes qui est intéressant!

#2

Salut,

J’aime bien le pull; Les scripts sont centralisés sur la machine qui accueille les sauvegardes.
Les outils sont uniformisés (utilisation de rsync pas ex), seuls les montages changent (cifs, nfs…) ou directement ssh s’il s’agit de Linux.

Push ou pull, tu est limité par la bande passante, débit montant ou descendant; Donc en matière de vitesse, c’est sensiblement la même chose.

Donc, bof… ça dépend de chacun, du parc, des outils,… :mrgreen:

#3

Le pull permet de mieux gérer la bande passante, car tu contrôles que 2 clients ne font pas une sauvegarde simultanément.
1 point pour le pull !

#4

[quote=“piratebab”]Le pull permet de mieux gérer la bande passante, car tu contrôles que 2 clients ne font pas une sauvegarde simultanément.
1 point pour le pull ![/quote]

Rien n’empêche d’ajouter l’argument nécessaire pour limiter la bande passante toi même.

lorsque tu doit centraliser sur une machine centrale tes backups (attention avec la centralisation) et que tu doit gérer plusieurs machines une solution tel que Bacula (mais il y en a d’autre) te permettront de les ordonnées et d’un coup d’oeil vérifier leur accomplissement via une web-ui.

Sinon il te faudra t’armer de scripts et jouer au cron ( :005 j’aime bien joué au C.R.ON).

Sinon dans le mêm style une web-ui permettant d’administrer tes backups.

#5

Hello,

Est-ce vraiment nécessaire, pour 2 postes, de mettre en place une telle architecture ?
Pour ma part, j’utilise Unison sur mes 4 ordinateurs. Ils se synchronisent via mon serveur quand je le souhaite.
Le fichier de configuration d’Unison (.prf) est déposé sur le serveur et les autres clients le récupèrent pour se configurer.
Ce n’est pas une sauvegarde complète mais seulement une copie, sur un serveur distant, des fichiers présents dans ~/Documents.

LeDub qui aime bien la simplicité d’Unison

#6

L’interet est aussi didactique (c’est ce que j’essaie d’expliquer à ma femme qui me voit bricoler des trucs qu’on trouve tout fait dans le commerce)

#7

[quote=“LeDub”]Hello,

Est-ce vraiment nécessaire, pour 2 postes, de mettre en place une telle architecture ?
Pour ma part, j’utilise Unison sur mes 4 ordinateurs. Ils se synchronisent via mon serveur quand je le souhaite.
Le fichier de configuration d’Unison (.prf) est déposé sur le serveur et les autres clients le récupèrent pour se configurer.
Ce n’est pas une sauvegarde complète mais seulement une copie, sur un serveur distant, des fichiers présents dans ~/Documents.

LeDub qui aime bien la simplicité d’Unison[/quote]

Quatres serveurs (dont certains héberge du VPS), deux postes fixes, deux portables, deux serveurs virtuels à mon travail, deux hébergement de type mutualisés aussi à mon travail et enfin trois portables de la famille à sauvegarder de façon différents à chaque fois (régularité des sauvegardes, données à sauvegardées, le tout en différentiel et incrémental).

Maintenant on rajoute à ça une possibilités de ‘rollback’ facilement et effectivement le type d’installation que j’aborde est utilie, en plus elle peu tout à fais être didactique pour un déploiement plus restreints tout en permettant une gestion fine de ces sauvegardes.

La simplicité à du bon certes, et j’admets que pour de la sauvegarde semestriel de deux postes je me prendrai pas la tête comme ça malgré tout le côté j’apprend et j’apprécie un truc fonctionnel est sympathique.

#8

Autre avantage du pull : si la machine que tu veux sauvegarder est compromise, l’attaquant n’aura pas accès aux backups. Dans le cas du push, si tu veux que tes sauvegardes puissent se faire de manière automatisée, il faudra laisser un accès en écriture vers le serveur de sauvegarde sans mot de passe.
En supposant que le serveur de sauvegarde ne fasse que des sauvegardes, il aura théoriquement moins de chances d’être compromis que ceux qui ont d’autres services qui tournent. Et il a seulement besoin d’un accès en lecture à la machine à sauvegarder.

Avantage du push : c’est plus simple pour les machines qui ne sont pas allumées à horaire fixe.

#9

Salut,
Je vois un autre avantage au pull, rien à installer sur les machines à sauvegarder à part:

Unix: serveur SSH
Windows: Autoriser les montages distants pour une seule IP (au travers d’un tunnel c’est encore mieux).

Dans le cas des push à partir de machine windows, ça impose l’installation d’un programme supplémentaire.

Pour les machines sous Windows, j’utilise un script qui ouvre un tunnel, monte le répertoire, fait un rsync, démonte et ferme le tunnel;
Pour les Unix, un rsync sur ssh.

#10

sous windows, j’ai vu qu’il y a un “truc” installé de base pour les sauvegarde. Le repertoire du NAS destiné à la sauvegarde est visible dans le voisinage réseau. Donc faire du push à l’air simple.
Ce que je retiens de vos messages:

  • le pull permet de centraliser, plus sécuritaire, mais plus complexe à mettre en oeuvre
  • le push est simple à mettre en oeuvre, mais nécessite un logiciel sur chaque machine, et on n’a pas une centralisation des échecs de sauvegarde.
#11

Lut,

Pour moi la question du pull ou push ne se pose pas dans ton cas.
Sur un LAN avec des PC fixes et administrés par tes soins c’est pareil au final.

Par contre si tu comptes pouvoir ensuite sauvegardé des machines nomade alors là la question devient intéressante.

A ta place je me concentrerai sur l’outil de sauvegarde que je veux utilisé (ses fonctionnalités, admin, facilité de gestion etc…).
Je me suis poser la même question dernièrement et j’ai opté pour du pull avec backup-pc.
backup-pc à l’avantage
de ne pas être trop complexe à mettre en oeuvre (dans mon environnement perso)
De gérer l’IPv6 (prérequis dans mon cas et bien pratique pour tout un tas de chose en fait ^^)
de fournir une WebUI par la gestion des sauvegardes backup restore etc.
de gérer plusieurs protocole
de ne pas nécessiter d’agent sur les clients…

Bref de mon point de vu si tu n’as pas un besoin impérieux de pull ou push regarde plutôt quel outil te convient le mieux, le reste viendra avec .
Voila my 2 cents :slightly_smiling:

#12

Globalement, c’est le pull qui se dégage de vos expérience, peut être parce que vous étes déjà des administrateurs avertis.
Dans mon cas, le serveur de sauvegarde est un NAS synology, et je ne peux pas installer grand chose dessus, à part du rsync.
Voici un exemple de ce qu’il faut faire, pas aussi simple qu’un apt-get install …
king76.au-quebec.info/2011/01/fa … -synology/
Je crois que je vais couper la poire en 2:

  • pull pour mes machines sous debian (mine de rien, il commence à y en avoir une dizaine …)
  • push sur la machine windows
#13

Salut !

Pour ma part, j’ai également choisi le pull. Je trouve que c’est plus logique. D’abord, si le parc informatique est vraiment fourni, cela peut être très lourd de déployer le système sur tous les clients. Et recommencer à chaque changement de configuration. Ensuite, d’un point de vue de la sécurité, tous les clients n’ont pas un accès direct au serveur. Ce qui n’est pas plus mal :slightly_smiling: Concernant les machines nomades, certains serveurs de sauvegarde prennent en compte ce paramètre et testent l’état (allumé ou éteint) du client afin de savoir s’il peut sauvegarder ou pas. Si c’est le moment d’effectuer une sauvegarde et que le client n’est pas accessible, il met la tâche en attente jusqu’à ce que le client se réveille.

Perso, j’ai choisi BackupPC que je trouve super. J’utilisais auparavant Bacula, mais je ne le trouve pas très ergonomique. Par contre, pour une personnalisation au centième de poil de couille, Bacula est idéal ! On en fait ce que l’on veut.

Concernant la communication client/serveur, dans mon cas, cela se passe le plus souvent par Rsync via SSH et clefs RSA. Le processus de sauvegarde est exécuté par un utilisateur aux droits réduits (nommé backup) avec sudo. Cet utilisateur n’a de « droits sudo » que pour executer Rsync, rien d’autre.

Concernant les NAS Synology, je crois que nombre d’utilisateurs parviennent à y installer Debian.

#14

Enfin quelqu’un qui utilise correctement sudo :wink:
Merci pour tout vos conseils.
Je ne vais pas tenter l’aventure de debian sur le NAS synology. Avec le firmware qui est installé par défautinstallé, le pull est assez compliqué à mettre en place, il faut en fait ce logguer via un terminal, et faire des scripts. Rien d’insurmontable, mais mise au point qui risque d’être laborieuse.
J’ai donc choisi le pull depuis les 2 ordis de bureau (une debian avec luckybackup et montage NFS, une win avec l’outil microsoft et montage CIFS).

Pour les autres machines, je vais faire des images disques que je vais mettre manuellement sur le NAS.

#15

Salut !

J’ai un peu le même problème que toi sur un site où se trouve un NAS Lacie que j’aimerais transformer en serveur de sauvegarde. Mais le soft n’est pas vraiment fait pour (c’est plutôt conçu pour faire un partage réseau). Il existe apparemment aussi une bidouille pour le passer sur Debian… Je crois que je ne vais plus parvenir à resister très longtemps :slightly_smiling: