[Admin-ml] Logiciel de sauvegarde sur NAS

Pierre Malard plm at teledetection.fr
Sam 22 Déc 01:00:38 CET 2012


Le 21 déc. 2012 à 15:01, Nicolas Alex Alex Michel <nicolas-michel at bluewin.ch> a écrit :
> On 21 déc. 2012, at 11:40, Pierre Malard wrote:
>> Ok, polémique, c'est une question de goût.
> 
> Précisément pas.
> On établis un cahier des charges, on met en concurences les solutions les plus proches de ce cahier,
> puis on test. On devrait s'efforcer de laisser de côté nos préférences personnelles pour tenter d'être objectifs.
> 
> TimeMachine a une très grande qualité : La simplicité.
> C'est 10'000 x mieux que pas de backup du tout et 100 x mieux que un backup qu'on doit enclancher à la main et qu'on oublie de faire.
> On plug et ça marche.
> 
> Mais après, utiliser cet outil clairement pensé pour le particulier dans un cadre professionnel a des limitations
> qu'on peut accepter, ou pas, suivant le cahier des charges.
> 
> Bon, désolé, mon style est un peut "tout ou rien", j'y peux rien : c'est mon style :)

No problemo.

Je ne dis pas que TM est la panacée, je voulais simplement dire qu'il ne fallait pas le repousser d'un revers de la main. En fait, comme tout outil très simple, le cœur est complexe et demande une bonne connaissance d'Unix et des subtilités de rsync et des liens d'inodes (hard links) utilisés pour assurer les incrémentales. D'où ma proposition de rsnapshot qui travaille dans la même veine.

>> Pour moi, c'était juste un retour d'expérience, rien de plus, rien de moins.
> 
> Merci pour ce retour, c'est toujours intéressant.
> 
> Ici on a eu quelques pertes de données de gens qui avaient choisis TimeMachin. 
> Pour moi l'utilisateur ne doit en aucun cas être responsable de ses sauvegardes parce que le taux de fiabilité des utilisateurs est plus faible que celui de Windows 95.

Ici, on a pas véritablement connu de problèmes bloquants. Il y a eu effectivement des pertes d'index lorsqu'on arrive en limite de quota sur le serveur. C'est très gênant car Mac OS X considère alors la perte totale des données et recommence une indexation depuis 0 mais on peut toujours récupérer les anciennes sauvegardes en intervenant sur le serveur. C'est un peu compliqué , je ne m'étendrais pas là dessus. Par contre, les nouvelles versions 10.7 et surtout 10.8 ont intégré le fait qu'on peut avoir plusieurs supports de sauvegardes et donc relire un disque ou un autre pour récupérer des données.

>> Si tu veux une solution "admin", pourquoi ne pas creuser du côté de "rsnapshot" (http://www.rsnapshot.org)
> 
> Intéressant, je ne connaissait pas.
> Ici on a BackupPC côté serveurs Linux, Atempo côté serveurs Windows et CrashPlan PROe côté clients.

Je ne connais pas BackupPC mais il semble également s'appuyer sur rsync. L'avantage est le côté Windows de ce produit. Je dois bien avouer avoir abandonné l'espoir de pouvoir faire une sauvegarde complète et simple d'un poste Windows. On s'appuie ici sur un partitionnement C=système+logiciels, D=Données et espace utilisateurs. On utilise Clonezilla pour faire des images système et logiciels, on configure les postes pour que toutes les données soient sur D: et on replante une image système s'il y a le moindre problème (virus, addware, et autres m....). C'est peu satisfaisant car l'utilisateur perd alors les softs qu'il avait ajouté seul mais ça nous permet de substantielles économies(de temps et donc d'argent) en cas d'infection. En plus, on leur conseille des softs comme "Cobian Backup" et un espace réseau Samba pour effectuer leurs sauvegardes de données.

>> Il suffit de s'assurer que le système de fichiers utilisé pour la sauvegarde est compatible avec HFS+; certainement pas un FAT ou NTFS, mais un ETX, pourquoi pas ?
> 
> NTFS est un bon fs qui supporte beaucoup des spécificités de HFS+, si ce n'est toutes : resource fork, hard link, …
> Par contre que Windows gère tout ça, là j'en doute. 
> 
> ETX, ext4 ? Ah tien, oui, je ne savais pas qu'il gérait les forks.
> Le problème est souvent aussi dans le protocole de transfert. Par exemple la version standard de rsync livrée dans les distro Linux ne supporte pas l'option --extended-attributes.
> Est-ce que rsnapshot gère correctement les resources ?

Tout ça (extended-attributes) n'est véritablement important que pour le système. Si on parle des espaces utilisateurs (/Users), ça a moins d'importance. Tout ce qui est ACL sous Mac OS X s'appuie sur les ACL Unix (FreeBSD) et sont donc très bien gérés par rsync. Pour ce qui est des ressources Apple, je dois bien avouer que je ne m'en étais pas inquiété depuis Mac OS ... 9. Et je n'ai jamais rencontré de problèmes résultant d'un rsync d'un Mac sous HFS+ sur un Linux sous Ext4. Peut-être n'ai jamais eu besoin de fichiers contenant des ressources Apple ?
Linux, via Fuse, gère relativement bien le NTFS (Mac OS X également d'ailleurs). Par contre, je n'ai jamais rien vu de probant pour gérer du HFS+ sous Linux. D'autre part, je pense que chaque système gère très bien ses FS natifs, c'est pourquoi je n'aurais pas tendance à conseiller un FS NTSF géré par un Linux. Ce serait ajouter une source de problèmes au problème. De la même manière, bien que "hfsplus", "hfsutils" et "hfsprogs" permette la gestion d'HFS+ sous Linux Debian, il me semblerait risqué de baser une sauvegarde là dessus.

Il me semble même que la solution trouvée par Apple de sauvegarde sur des "sparse bundle disk image" dès qu'on utilise TM sur un réseau vienne grandement de la résolution simple de la question posée. Ça permet de toujours présenter un FS HFS+ au Mac quelque soit le FS distant et ça permet d'ajuster la taille du pseudo disque présenté en ajoutant des bouts au besoin...

Cependant le problème posé est intéressant. C'est un peu pour ça que je proposais d'utiliser un Mac sous Mac OS X, gérant donc un FS HFS+ en natif. Le truc est de le transformer en Mac OS X "Server" sans passer par Apple. C'est pourquoi je parlais de MacPorts. un vieux Mac Pro Intel ferait un excellent candidat au regard de ses possibilités d'extensions matériel.

Dernière chose qui peut être intéressante. En fouillant un peu le net, j'ai trouvé cet article traitant justement de l'utilisation de rsync entre Mac et Linux et des "extended attributes" Mac OS X. Il semblerai qu'on puisse s'en tirer avec une version > 3.0.6 de rsync installée sur le Mac (v 2.6.9 sous Mac OS X 10.8). MacPorts en propose une en 3.0.9. Tu peux lire ça sur http://www.kernelcrash.com/blog/using-rsync-to-backup-from-osx-to-linux/2009/06/20/. Il y est fait également référence à LBackup qui semble être au point pour traiter spécifiquement les problèmes de "ressources fork" Apple (http://www.lbackup.org).

Perso, je vais regarder ça pour affiner la sauvegarde de nos Macs. Cette discussion m'a ouvert des perspectives intéressantes, merci donc.

Coridalement

----
A propos de nos chers économistes :
    «Les habiles, dans notre siècle, se sont décernés a eux-mêmes la 
    qualification d’homme d’état. [...] ces politiques, ingénieux
    a mettre aux fictions profitables un masque de nécessité.»
          Victor Hugo : “Les misérables”, La pléiade, Gallimard, P. 843
   |\      _,,,---,,_
   /,`.-'`'    -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)

perl -e '$_=q#: 3|\ 5-,3-3,2-: 3/,`.'"'"'`'"'"' 5-.  ;-;;,-:  |,A-  ) )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(-/--'"'"'  `-'"'"'\-): 22PLM::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



Plus d'informations sur la liste de diffusion Admin-ml