Il me semble avoir deja verifie mais CrashPlan Pro ne supporte pas non plus les NAS je crois?
Elle le permettait avec un vieux hack, et c’etait pas “supporté” officiellement.
Teste aussi la restauration des données.
Bon, donc voici les tests que j’ai en cours… je rappelle ma situation:
- Toutes mes donnees sont sur un NAS Synology, donc je veux pas d’outils desktop genre SyncBack et autres.
- Ca prend entre 1.5To et 4To en fonction de si je backup le strict necessaire ou bien d’autres trucs en plus genre les backups de mes achats lecture/musique/video/etc.
- Il faut que ca soit facile de verifier que le backup marche.
- De preference, de l’historique a 30 jours ou plus sur les fichiers (bref: du backup, pas du sync).
- Quand j’aurai fait une upgrade de mon hardware local de facon a avoir de la place pour gerer l’historique moi meme, ca simplifiera, j’aurai sans doute juste besoin d’une solution de sync dans le cloud (a moins de vouloir avoir l’historique a 2 endroits).
- De preference, encryption du bousin quand ca va dans le cloud (j’ai deja des backups en clair ailleurs).
Resultats preliminaires:
-
HyperBackup vers Amazon Drive
- Ca cree une DB proprietaire Synology mais explorable avec leurs applis desktop si jamais le NAS meurt.
- L’avantage c’est qu’il gere l’historique des fichiers.
- On dirait qu’une fois cree, le backup ne peut pas etre modifie pour rajouter/enlever des repertoires source… ce qui est mega chiant, a moins que j’aie rate quelque chose.
- Ca a mis genre 6 jours pour uploader les 1.5To… mes limites d’upload pour Aout sont atteintes, je crois que mes tests en septembre se feront sur des plus petites tailles
- D’apres des commentaires de gens sur les forums Synology, il semble que HyperBackup soit (ou etait a une epoque) considerablement plus lent que d’autres outils. Les gens de Synology disent qu’ils ont optimise depuis, mais d’apres mes precedentes experiences avec HyperBackup en local entre mes differents NASs, ca m’a l’air toujours beaucoup plus lent qu’on bete rsync par exemple.
-
CloudSync vers Backblaze B2
- CloudSync ne gere pas l’historique, mais B2 le fait pour lui en theorie vu que la sauvegarde est faite fichier par fichier tout simplement. Par contre il semble qu’on doit se taper l’API B2 pour retrouver les vieilles versions, donc probablement trop chiant en pratique pour etre utilisable.
- B2 est pas dispo en backend pour HyperBackup mais les gens de Synology disent que c’est dans les plans pour 2018.
- J’ai des erreurs dans l’interface DSM, ca refuse de creer le backup
-
Duplicity vers Backblaze B2 (y’a pas de support Amazon Drive pour l’instant)
- La version Synology est dispo chez SynoCommunity.
- Si je comprends bien l’outil gere l’historique des fichiers avec un mix de stockage incremental entre versions et de duplication complete.
- Pour l’instant j’ai juste fait un tout petit test pour voir que c’est facile a utiliser et que ca marche sur l’OS Synology.
-
Rclone vers Backblaze B2
- Les binaires dispo sur leur site pour Linux x64 tournent sans probleme sur un Synology avec une archi CPU compatible, c’est surprenant (c’est magique le cross-compile en Go apparemment)
- Pareil que precedemment, j’ai juste fait un petit test pour voir que ca tourne sur le NAS.
- Pas d’historique de base (c’est juste un « rsync pour le cloud », comme ils disent), donc comme pour CloudSync, y’aurait pas d’historique en pratique.
- Les binaires dispo sur leur site pour Linux x64 tournent sans probleme sur un Synology avec une archi CPU compatible, c’est surprenant
Ca va probablement prendre quelques semaines pour finir de tester tout ca 
L’historique des versions n’est pas pris en charge de base par bucket dans backblaze? Dans Lifecycle Settings.
Sinon j’ai une question avec duplicity. Quand il fait un full backup entre plusieurs backups incrémentaux; ca signifie qu’il re-uploade tout? Ou bien juste le diff entre le dernier full backup et le nouveau?
Pour le coup vu que dans HyperBackup tu as des options de déduplication, de compression, de cryptage et de versionning, c’est un peu normal que ça soit plus lent qu’un bête rsync (je ne sais pas si c’est vrai vers un Amazon Drive)
Oui c’est pris en charge, mais je veux dire que pour recuperer par exemple tout un repertoire comme il etait il y a 2 semaines, passer par l’interface B2 serait super mega chiant, probablement, et donc je prefere pas compter dessus a moins qu’il y ait une abstraction plus simple devant.
Duplicity me confuse toujours (la doc est digne d’un logiciel open source), mais non, si tu fais un full backup, ca re-uploade tout en effet. La difference entre le dernier full backup et la version courante c’est seulement quand tu fais un backup incremental.
Du coup, a moins de garder l’historique de tous ses fichiers ad eternam je pige pas bien l’interet parce que si on veut economiser de la place et virer les vieilles versions qui ont plus de 60 jours par exemple, on ne peut pas le faire sans virer le premier full backup+tous les backups incrementaux depuis, et refaire un autre full backup (parce que la « granularite » de Duplicity c’est le backup lui meme – pas chaque fichier). Bref, j’ai l’impression que soit j’ai pas compris un truc, soit c’est de la merde.
La plupart des gens sur le forum l’utilisent sans compression ou cryptage, donc il ne devrait y avoir que l’overhead du versioning. Mais c’est genre 2 ou 3 fois plus lent que rsync – pas genre 20%. La deduplication je sais plus si on peut la desactiver mais c’est aussi superflu dans beaucoup d’utilisations.
Quel interet y a-t-il a refaire des full backups alors? Pourquoi ne pas faire que des incrementaux suite a un premier full backup?
Parce que c’est dangereux de ne faire que des backups incrémentaux. Suffit qu’un backup dans le lot soit en vrac pour potentiellement perdre tous les suivants.
Et aussi parce que en faisant des backups incrementaux tous le temps, au bout de 10 ans on se retrouve avec 12000Tb de backups et pour restaurer un fichier tel qu’il était une heure avant, il faut le restaurer tel qu’il était 10 ans auparavant et appliquer (10 ans - 1h) d’incréments…
Je viens de regarder une douzaine de tutoriels sur l’outil et ils font tous un script qui fait un full backup tous les 7 jours ou autres. Aussi ils ont l’air de tous faire des « petits » backups, genre un répertoire de documents, un site web, ou les fichiers de configuration d’un serveur. Donc je crois que c’est pas adapté à ce qu’on veut ici.
Je pensais au début que Duplicity faisait plutôt des backups par fichier (plutôt qu’un énorme fichier tar pour toutes les données), et que quand on voulait se débarrasser de backups plus vieux de X jours, il reconstruisait une « base » (i.e. un full backup) en « écrasant » le full backup d’origine avec tous les backups incrementaux qui suivent, jusqu’a X jours… bref, un truc utile, quoi mais apparemment non (à moins que je rate un truc).
Prochain tests: rclone et borgbackup.
Je me permet une petite question, n’y voyez aucune provocation, mais l’historisation des fichiers sur 30 jours, hormis pour une utilisation pro, ça a vraiment un intérêt pour du backup online ?
Je me disais exactement la même chose et je me suis répondu “non.” Le diff c’est surtout bien pour diminuer le temps d’upload en ce qui me concerne.
L’intérêt que j’y trouve c’est que si je me prends un ransomware et que je n’arrive pas à intervenir avant que les données chiffrées n’aient commencé à écraser mon backup, je peux toujours me tourner vers l’historique.
(ça marche aussi en cas de fausse manip)
2 « J'aime »
Pardon j’aurais du préciser dans le cas où il y avait un backup avec historique en local de fait.
Si t’as un backup avec historique en local, c’est pas vraiment necessaire, non. Comme je le disais plus haut, la raison pour laquelle, si possible, j’aimerais un historique dans le cloud, c’est tout betement que mon backup local (un autre NAS dans mon cas) est deja relativement plein, et donc pas la place de stocker beaucoup d’historique… donc en attendant de pouvoir claquer $1000 ou plus dans des nouveaux disques et peut etre un nouveau NAS, je me dis que je peux le mettre dans le cloud pour l’instant.
Oui c’est bien d’avoir l’historique comme tu dis pour les ransomware, mais même dans ce cas 30 jours pour des données perso c’est peut-être beaucoup. J’y réfléchissais tout à l’heure en bagnole et je me disais que 3 jours ça serait certainement suffisant.
D’après ce que j’ai compris, borgbackup t’oblige a d’abord créer le backup sur un disque local, avant de l’envoyer sur le cloud… Du coup faut pas mal d’espace libre 
Il me semble que si t’as un access SSH quelque part tu peux initialiser le repository directement en remote?
Oui. Mais du coup, pas backblaze