Fenrir

Je n'ai pas vu si tu avais indiqué ton modèle de nas (le mettre en signature c'est pratique), mais s'il gère le BTRFS, les versions de cloudstation prennent bcp moins de place. Maintenant vu l'architecture technique de CloudStation, je peux de garantir qu'il n'est pas du tout taillé pour absorber des gros volumes (en taille et en nombre de fichiers). Dans ton cas, si ton flux est unidirectionnel, rsync (ou n'importe quel autre soft de sauvegarde) sera bien plus efficace, fiable et rapide.

et/ou de ça :

3617 plutôt non ? Ça commence à faire gros, on trouve des netapp à ce prix là, juste par curiosité, c'est pour quel usage ? ------------ Sinon ta demande est, comment dire, tellement peu détaillée qu'il est impossible d'y répondre de manière précise. Donc je te fais une réponse générique : Tout dépend de ce que tu veux migrer et dans quelles conditions. Par exemple si tu souhaites juste migrer les données des partages, Synchro du dossier partagé est très bien, mais rsync en direct (en commande) c'est encore mieux. Pour les luns ça dépend de si elles sont en mode disque ou fichier, mais je crois qu'HyperBackup gère les 2 modes Pour la conf, tu peux faire un export/import, mais je te le déconseille (trop de différences entre le 2 modèles), par contre avec un peu d'huile de coude tu pourras récupérer la plupart des paramètres, voir tous (ça dépend de ce que tu utilises).

mais pas avec les bons droits, donc elle n'est pas utilisable (tu as certainement une erreur dans les logs du syno qui te l'indique) -rw------- 1 HyperBackup HyperBackup 1679 Jan 20 23:25 id_rsa -rw-r--r-- 1 HyperBackup HyperBackup 390 Jan 20 23:25 id_rsa.pub ################################ pas le bon ################################ et pas correctement ################################ C'est à dire ?

Je n'utilise pas vraiment SurveillanceStation, je fais juste joujou de temps en temps, mais vous n'avez jamais pensé à faire un petit script autour de ffmpeg pour alléger les vidéos après un certain temps ? J'imagine un truc du genre : SurveillanceStation : enregistrement en qualité 1080p@30fps (par exemple) durée max d'un fichier 1h rétention 1 mois ou 100Go (au pif) Script : toutes les heures, un petit script avec ffmepg sur la vidéo t-1 pour réduire la résolution, baisser le frame rate, baisser le bitrate et virer l'audio afin d'archiver une version light dans un autre dossier tous les mois, suppression des archives de plus de 6 mois (au pif) Je viens de tester sur mon 712+ (assez puissant mais pas de première jeunesse), en ajustant bien les paramètres j'arrive à compresser en à peu près autant de temps que la durée de l'enregistrement avec en sortie un résultat "regardable". Par exemple avec ces options (on peut surement faire mieux, je n'ai pas creuser) : ffmpeg -y -i camera0120170119-073131-1484807491.mp4 -r 10 -c:v libx264 -s 640x480 -crf 35 -preset fast -an -movflags +faststart test.mp4 => une vidéo de 11mo (1minute à 1080p@30fps en mode nuit) ne fait plus que 90ko en sortie (j'ai bien écrit kilo octet). Si vous avez un modèle qui gère le transcodage matériel ou que vos enregistrements sont dans une résolution plus raisonnable, ça devrait passer sans soucis avec une qualité correcte. Après c'est un équilibre à trouver entre espace disque, qualité et durée de rétention.

Le moins de choses possible en fait ! J'ai pour habitude de toujours serrer les vis au maximum, là j’avais juste trop fermé ma conf, donc j'ai tout viré, pour ne garder que le minimum : cat /home/machin/rsyncd.conf socket options = SO_KEEPALIVE use chroot = no [module01] path = /home/machin/test/1 comment = module 1 auth users = machin,truc,chose secrets file = /home/machin/rsyncd.secrets read only = false [module02] path = /home/machin/test/2 comment = module 2 auth users = machin,truc,chose secrets file = /home/machin/rsyncd.secrets read only = false Reste encore à trouver comment utiliser une clef ssh edit : C'est bon pour la clef, il faut juste l'installer dans /var/packages/HyperBackup/target/.ssh

C'est bon ça marche

sur le serveur évidemment, ceux du syno on s'en fou dans le cas présent mais sinon ils sont dans /var/log/rsync.error : @ERROR: chroot failed on est vachement avancé avec ça ...

Je suis entrain de tester. Sans chiffrement du transfert aucun problème, ça marche du premier coup. Par contre avec le chiffrement j'ai un problème, mais comme il est hors de question que j'utilise un compte root ... Pour le moment je bloque la dessus : Jan 20 22:36:14 xxxxx sshd[29927]: Accepted password for machin from xxx.xxx.xxx.xxx port 37842 ssh2 Jan 20 22:36:14 xxxxx sshd[29927]: pam_unix(sshd:session): session opened for user machin by (uid=0) Jan 20 22:36:14 xxxxx rsyncd[29930]: connect from monsyno (xxx.xxx.xxx.xxx) Jan 20 22:36:14 xxxxx rsyncd[29930]: rsync allowed access on module module01 from monsyno (xxx.xxx.xxx.xxx) Jan 20 22:36:14 xxxxx rsyncd[29930]: rsync: chroot /home/machin/test/1 failed: Operation not permitted (1) nb : contrairement à ce que je pensais, le HyperBackup n'est pas foutu d'utiliser des clefs ssh edit : en fait si, le piège c'est qu'HyperBackup n'est pas lancé en root sur le syno mais avec un compte dédié, c'est tellement rare chez syno que quand ils font les choses bien, on se fait avoir ps : sans passer par Hyperbackup mais directement en ligne de commande ça fonctionne sans soucis

Pas nécessairement, ça dépend de l'état des disques en question

Je veux dire que je pense qu'Hyperbackup essaye de se connecter en ssh et que pour s'authentifier il utilise une clef ssh (c'est la méthode la plus courante). Mais comme cette clef n'est pas installée, il n'y arrive pas. Maintenant je n'ai pas testé ni même regardé. Ça c'est sur que ça fonctionne, mais ça ne sera plus géré par Hyperbackup. En utilisant le serveur rsync, tu utilises le protocole rsync, donc le transfert n'est pas chiffré (mais authentifié avec un login/pass à déclarer dans rsyncd.secrets). En utilisant ssh, pas besoin de serveur rsyncd (mais peut être qu'Hyperbackup s'en sert) car ssh peut écrire directement sur le disque distant via scp et le transfert est chiffré. Donc reste à savoir comment fonctionne HyperBackup. Une clef ssh ce n'est pas un certificat (même s'ils partagent certaines technos). --------- Je vous ai trouvé 3 docs, la dernière devrait correspondre à vos demandes http://synology.pc-fute.com/2015/10/sauvegarde-du-nas-synology-vers-un-serveur-rsync/ http://pled.fr/?p=10062 https://ludovicscribe.fr/blog/sauvegardes-cryptees-raspberry

Tu as fait le test avec un linux ?

C'était un exemple (et encore, pas certain que ton soft soit capable de voir quoique ce soit en lien avec linux), je ne vais pas rentrer dans le détails (trop de choses à dire et à t'apprendre, c'est très compelxe un système de fichiers), dis toi juste que si le soucis est mal placé, tu peux tout perdre. Tu peux tester ça, aucune idée de si ça fonctionne : http://www.chrysocome.net/virtualvolumes Mais ça reste plus fiable de le faire depuis un Linux, au moins tu as tous les vrais outils (les même que dans le syno).

Par contre, selon les soucis qu'ont tes disques, il n'est pas certain que ça n'efface pas tout. Si c'est juste la partition système qui a du plomb dans l'aile, pas de problèmes, mais si c'est la tables des partitions, c'est bcp plus risqué

, ça n'apporte rien sinon de risquer de t’emmêler les pinceaux. Fais plutôt ceci : CN : description1.domaine.fr SAN : description1.domaine.fr, appli1.domaine.fr, appli2.domaine.fr, appli3.domaine.fr, appli4.domaine.fr CN : description2.domaine.fr SAN : description2.domaine.fr, appli5.domaine.fr, appli6.domaine.fr, appli7.domaine.fr, appli8.domaine.fr nb : techniquement possible ne veut pas dire que c'est géré par lestencrypt ou le syno Letsencrypt est un service gratuit pour que les particuliers (ou les petites entreprises) puissent créer des certificats de manière simple et gratuite pour un usage raisonnable. De plus générer des dizaines de certificats va te poser des problèmes logistiques et techniques. https://letsencrypt.org/docs/rate-limits/ Si tu tiens à aller plus loin, il faut prendre un certificat wildcard (c'est payant) ou créer ta propre autorité (c'est ce que j'ai fait) Autant monter un chroot, ça évitera de modifier des fichiers de conf qui pourraient être écrasés lors de mises à jours.

cherche "LVM linux" dans ton moteur préféré Ton disque devrait être "coupé" en 3 partitions La première c'est le système (elle sera en raid1), tu peux avoir besoin de certains fichiers dans /etc (pour LVM justement) La deuxième c'est la swap, aucun intéret pour toi Et la troisième contiendra tes données, par contre en SHR c'est : une couche de raid1 puis une couche de LVM et enfin le système de fichiers (ext4 probablement)

Techniquement oui, mais je n'en vois pas l’intérêt pour un particulier.

Sinon tu peux aussi utiliser la taille de clef par défaut (elle fait combien ?) et ne pas mettre plus de 10 SAN par certificats (tu peux créer plusieurs certificats), ça sera plus simple pour toi je pense.

La version de Linux avec laquelle tu es le plus à l'aise, si tu n'en connais pas, prends ubuntu comme dans la doc (je n'aime pas ubuntu, mais si c'est juste pour restaurer un DD, ça fera l'affaire). Si tu es en SHR, un seul disque est suffisant, par contre la doc est insuffisante car il manque la partie LVM (utilisée par SHR), mais il y a plusieurs posts sur le forum avec les infos.

Oui, ça va te couter un rendez-vous récurrent dans ton agenda Sinon avec docker (si ton nas le gère) ou un chroot debian, tu peux le faire depuis le syno et tout automatiser

Ils étaient en quoi tes disques ? basic : il existe des softs permettant de lire du ext4 sous windows et mac raid X : pas possible sous windows et j'en doute sous mac shr : idem Par contre, une VM avec un linux devrait faire le travail : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC

Je te donne celui là, le reste est simple à trouver. $? contient le code de retour de la dernière commande

Un "sous domaine" ça n'existe pas, www.toto.truc est un domaine au même titre que toto.truc ou que truc. En théorie il n'y a pas de limite, en pratique il ne faut pas en mettre trop car ça charge inutilement les serveurs, les navigateurs et le réseau. Ça peut même conduire à tes erreurs d'interprétation. En général on se limite à une dizaine, je crois que letsencrypt en permet 100 (j'ai un certificat letsencrypt avec 14 SAN, pas de soucis). Je ne l'utilise pas et je n'ai rien vu dans la doc à ce sujet donc je ne peux pas te répondre. Tu veux en mettre combien ? Oui En générant ta clef publique à la main (avec openssl par exemple). Mais dans ce cas, autant générer aussi la demande de certificat letsencrypt. nb : si tu comptes utiliser ton certificat pour de la messagerie et que tu as des échanges avec microsoft (outlook, exchange online, ...), utilises un certificat RSA, microsoft ne sait pas ce que c'est qu'un certificat à courbes elliptiques ...

Plusieurs choses faisable, mais ça dépend de ce dont tu disposes. Pour tester le nas, le plus simple et sûr c'est de prendre un autre disque sans rien dessus et de tenter de réinstaller DSM dessus. Si ça fonctionne, le nas va bien. Autre test simple à faire, vérifie que tu n'as pas simplement un soucis réseau Tu peux tester avec un seul des disques, puis l'autre Tu peux aussi tester le "contenu" de tes disques depuis un PC sous Linux (il y a la doc sur le site de syno) Tu peux tenter une réinstallation de DSM sur tes disques actuels (double reset, ça ne touche pas aux données) Mais avant tout, assure toi d'avoir une sauvegarde.

je n'ai pas mis de commentaires, c'est mal Si tu veux la traduction de telle ou telle ligne, n'hésites pas.