Condorman

Ok alors je comprends mieux le comportement. Resterai à connaitre l(es) adresse(s) IP source de Crashplan afin de les rajouter spécifiquement à mes filtres.

Pourquoi faut-il autoriser plus d'IP source que celles des PC qui ont besoin de se connecter à mon NAS ?

En fait, j'ai eu la surprise de le voir fonctionner. Entre temps, j'avais modifié la règle de redirection de port de mon routeur (Freebox V6) : au lieu de faire une règle par adresse IP source vers le port 4242 du NAS, j'ai mis une seule règle qui accepte toutes les adresses IP source...(j'aime pas trop ..) Là, les sauvegardes depuis mes 2 PC à l'exterieur de mon réseau ont fonctionné. Peut-être que les serveurs de crashplan auraient besoin de vérifier l'accès au serveur de destination de sauvegarde afin de communiquer l'info aux autres PC. En clair, si les serveurs de crashplan ne sont pas autorisés à accéder à mon NAS sur le port 4242(filtrage par IP source), les autres PC que je veux sauvegarder auraient une information comme quoi il n'auraient pas la possibilité d'avoir accès aussi via l'adresse WAN... Je trouve cela étrange.

J'ai un soucis avec mon crashplan installé sur mon NAS. Il fonctionne pour le PC sur le réseau local qui sauvegarde sur le NAS. La sauvegarde du NAS vers le cloud Crashplan fonctionne aussi. Mon soucis est avec les PC situés en dehors de mon réseau local. Ceux-ci n'arrivent pas à se connecter avec mon NAS alors que j'ai bien forwardé le port 4242 du routeur vers le NAS. Si depuis l'extérieur, je fais un telnet vers mon IP publique sur le port 4242, cela se connecte bien à crashplan. Le soucis est que les client crashplan situés à l'extérieur cherchent à se connecter sur l'adresse LAN de mon crashplan au lieu de l'adresse WAN... J'ai pu le constater avec wireshark. Cela est confirmé par le fait que si de l'extérieur j'ouvre mon VPN, là, ça fonctionne (car les clients arrivent à accéder à l'IP LAN de mon NAS). Bref, comment forcer les clients crashplan extérieur à utiliser l'adresse publique (WAN) de Crashplan au lieu de l'adresse LAN ? Il semble que ce problème soit récurent.

Bon, alors voilà comment cela se termine. Grâce à l'aide de @Gaetan Cambier, j'avais accès à mon volume1 où j'avais toute mes données accessibles. Avec mon disque en plus + des disques que j'ai branché en USB sur le NAS, j'ai réussi à sauvegarder tout ce qui me paraissait important. 3 jours après avoir rempli le formulaire du support Synology et auquel j'avais donné un descriptif détaillé des actions qui avaient été prises afin qu'ils comprennent bien dans quel état était mon NAS, le support m'a contacté par email. J'ai été assez déçu de leur réponse : Merci de votre réponse, dans un premier temps lorsque vous avez constaté le crash de votre volume vous devriez être en mesure d' attendre nos investigations sur votre NAS. Mais là vous avez déjà fait des manœuvres sur votre NAS et donc tout ce qui pourrait advenir sera de votre responsabilité. J' ai bien pu parcourir votre fichier pdf et constaté que vous avez en effet essayer de faire certaines commandes qui vous ont servi, mais pour des raisons de procédures je ne peux m' engager sur la démarche que vous avez suivi et donc je ne peux donner d' avis sur cette démarche. j' espère donc bien que vous aurez la possibilité de pouvoir sauvegarder toutes vos données. tout ce que je pourrai peut être faire c 'est l' analyse de vos logs et vous informer de l' état de votre volume avant le crash et aussi vous informer s' il y a des disques en cours de défection Bref, comme vous avez dû vous débrouiller tout seul, et bien continuez ... C'est dommage qu'ils ne traitent pas certaines situations peut être avec plus de réactivité que d'autre. Je vous explique pas déjà le stress que c'était quand mon problème est arrivé (je pensais avoir tout perdu) alors attendre 3 jours avant d'avoir un premier contact, c'est très très très long... Heureusement que dans mon job, on répond plus vite à nos clients... Après mes sauvegardes, j'ai donc tenté le reboot. Cela m'a amené dans exactement la même situation c'est à dire que le paramétrage du RAID de mon volume de données était absent. Alors, suite à un message lu sur un forum anglais, j'ai tenté la réinstallation du DSM. (après un reset sur le boitier) J'ai croisé les doigts jusqu'au bout et finalement, j'ai bien retrouvé mon volume comme quand il m'avait quitté. J'ai eu 1 message comme quoi la partition système du disque 2 était plantée. Il l'a réparé sans message d'erreur. Bon, il me reste à tout re-installer et à re--paramétrer les packages. (Au passage, mon md127 est redevenu md2 de base) Je m'en tire pas mal. Du coup, je suis devenu client de Crashplan et j'en ai pour quelques mois à tout sauvegarder (ADSL ....) car avant, je n'avais pas de sauvegarde de tout.... De tout manière, il faut que je me prépare à tout sauvegarder hors de mes 4 disques car j'aimerai remettre à plat ma config RAID et passer au btrfs quand celui ci sera disponible en mars prochain et comme il n'y aurait pas de migration possible, il faudra bien se débrouiller autrement ...

Ha OK, je comprends. Bon en tout cas, si tu passes un jour par La Rochelle, je te paye un coup à boire une bière ( belge :-) ?) ! Grâce à toi, j'attends avec moins d'impatience (pendant que mes copies se font) le support Synology..

OK. Je me pose juste la question de l'intérêt d'avoir associé la partition /dev/sde3 à un volume raid (md2) Est-ce qu'il n'aurait pas été possible de formater et de monter directement /dev/sde3 ? Dans ce cas, la partition n'aurait-elle pas été lisible par Linux et windows directement ? Merci

Dernière question : Est-ce que si je sors le disque, je pourrai le mettre dans un boitier USB et le brancher sur un windows. Il me semble que j'avais déjà réussi à lire une partition ext4. Est-ce qu'il en sera de même dans ce cas où c'est un disque issue d'une partition raid ? Pour la copie, j'avais mis un midnight commander sur le Ds1515+ et il fonctionne alors cela me permet de facilement me déplacer dans les répertoires et de faire mon choix ...

Ok super ! Sacré support ! Sino> mount /dev/md2 /volume2 Sino> cd volume2 Sino> df -h Filesystem Size Used Avail Use% Mounted on /dev/root 2.3G 1.4G 868M 61% / /tmp 3.0G 704K 3.0G 1% /tmp /run 3.0G 2.2M 3.0G 1% /run /dev/shm 3.0G 0 3.0G 0% /dev/shm none 4.0K 0 4.0K 0% /sys/fs/cgroup /dev/bus/usb 3.0G 4.0K 3.0G 1% /proc/bus/usb /dev/vg1000/lv 9.0T 8.4T 630G 94% /volume1 /dev/md2 3.6T 89M 3.6T 1% /volume2 Bon à présent je vais pouvoir faire mes copies, je peux déjà mettre 3.6 To de côté... Quelles seront les commandes avant de retirer le disque ? Je pourrai le retirer à chaud sans éteindre le synology ? Car j'avais vu le le service "hotplugd" n'avait pas été lancé au dernier démarrage foireux... Et si je veux re-mettre un autre disque après, comment cela se passe ?

C'est fait : Sino> mkfs.ext4 /dev/md2 mke2fs 1.42.6 (21-Sep-2012) Filesystem label=1.42.6-5592 OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 243900416 inodes, 975574944 blocks 25600 blocks (0.00%) reserved for the super user First data block=0 Maximum filesystem blocks=3124756480 29773 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done

Ok, c'est fait : Sino> mdadm --create /dev/md2 --metadata 1.2 --level=1 --force --raid-devices=1 /dev/sde3 mdadm: array /dev/md2 started. Sino> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid1 sde3[0] 3902299776 blocks super 1.2 [1/1] [U] md127 : active raid5 sdb5[5] sdd5[3] sdc5[2] sda5[4] 5846338944 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md3 : active raid5 sdd6[0] sdb6[3] sda6[2] sdc6[1] 2930228352 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md4 : active raid1 sda7[0] sdb7[1] 976646336 blocks super 1.2 [2/2] [UU] md1 : active raid1 sda2[0] sdb2[4] sdc2[1] sdd2[2] 2097088 blocks [5/4] [UUU_U] md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] 2490176 blocks [4/4] [UUUU] unused devices: <none> Sino>

Sino> mdadm --create /dev/md2 --metadata 1.2 --force --raid-devices=1 /dev/sde3 mdadm: a RAID level is needed to create an array. Faut il rajouter cela ? --level=raid0

Désolé, du coup j'étais parti me coucher ... Voilà le résultat des commandes : Sino> sfdisk -l /dev/sde /dev/sde1 256 4980735 4980480 fd /dev/sde2 4980736 9175039 4194304 fd Sino> synopartition --part /dev/sde 5 0 Device Sectors (Version6: 1-Bay) /dev/sde1 4980087 (2431 MB) /dev/sde2 4192965 (2047 MB) Reserved size: 257040 ( 125 MB) Primary data partition will be created. WARNING: This action will erase all data on '/dev/sde' and repart it, are you sure to continue? [y/N] y Cleaning all partitions... Creating sys partitions... Creating primary data partition... Please remember to mdadm and mkfs new partitions. Sino> sfdisk -l /dev/sde /dev/sde1 63 4980149 4980087 83 /dev/sde2 4980150 9173114 4192965 82 /dev/sde3 9430155 7814032064 7804601910 83 Est-ce qu'il ne faudrait pas sortir le sde du raid md1 ? md1 : active raid1 sda2[0] sdb2[4] sdc2[1] sdd2[2] 2097088 blocks [5/4] [UUU_U] avant c'était : md1 : active raid1 sda2[0] sdb2[4] sdc2[1] sdd2[2] sde2[3] 2097088 blocks [5/5] [UUUUU] D'ailleurs, je viens de recevoir un mail (il n'est pas complètement mort ...): Cher utilisateur, Le volume système (Swap) sur Sino est passé en mode dégradé. (Nombre total de disques durs : 5 ; nombre de disques durs actifs : 4) Veuillez redémarrer le système, et il se réparera automatiquement au démarrage. Sincères salutations, Synology DiskStation

Ok merci. Bonne nuit!

oui, c'est exactement ça que je pensais. Bien que j'ai déjà fait un ticket à Synology...