Condorman
-
Compteur de contenus
55 -
Inscription
-
Dernière visite
Messages posté(e)s par Condorman
-
-
Pourquoi faut-il autoriser plus d'IP source que celles des PC qui ont besoin de se connecter à mon NAS ?
0 -
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.
0 -
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.
0 -
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 ...
0 -
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..
0 -
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
0 -
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 ...
0 -
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 ?
0 -
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: done0 -
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>0 -
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
0 -
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 83Est-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
0 -
Ok merci.
Bonne nuit!
0 -
oui, c'est exactement ça que je pensais. Bien que j'ai déjà fait un ticket à Synology...
0 -
Merci Gaetan !
Volume 1 monté.
Je vois son contenu
J'ai pu lire le contenu d'un fichier
En revanche, le DSM est toujours dans les choux. Il m'indique que mes disques ne sont pas utilisés.
0 -
Sino> vgchange -ay 1 logical volume(s) in volume group "vg1000" now active
Sino> lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert lv vg1000 -wi-a- 9.08T
Je ne devrais pas avoir 10 To ?
0 -
Merci pour les conseils d'hier
Je n'ai pas encore franchi le pas de la commande
vgchange -ay
J'ai bien lu dans d'autres forum que cela devrait me permettre de ré-avoir accès à mon volume. Donc grâce à vos conseils, l'espoir est là.
(Au passage, j'ai lu qu'on pouvait lancer les commande pvscan et vgscan avant la commande vgchange -ay, est-ce utile ?)
Une fois le volume1 remonté, j'aimerai profiter de mon disque de 4 To en spare en baie 5 pour faire un backup d'une partie de mes données.
Ce qui m'inquiète, c'est que le disque sde semble posséder 2 partitions et que celles ci semblent associées au disque RAID md0 et md1.
Comment faire pour en faire une unité indépendante afin de l'utiliser comme disque de destination de ma sauvegarde ?
Est-ce que je peux (dois) passer par l'interface web de DSM pour le sortir du service secours à chaud au préalable ?
Si je dois le formater, quelle doit être la commande ?
Merci
0 -
Je n'ai pas rebooté ...
Donc il faut que je tape ces commandes :
vgchange -ay lvs
et ensuite, je pourrai monter le volume1 pour faire des sauvegardes avant de rebooter ? (avec quelle commande ?)
Est-ce que le nom "md127" ne risque pas de poser de problème car cela ne semble pas standard ....
Le volume group s'attend il à le trouver sous ce nom là ?
Je suis quand même super déçu d'avoir un NAS réputé de bonne qualité sur onduleur avec un disque de 4To en spare et d'en être rendu à me demander si je ne suis pas en train de tout perdre ...
0 -
Non, je n'ai pas installé DSM 6.0 béta ...
Voici le résultat de la commande :
Du coup, j'ai relancé la commande mdstat et il a complété ...
Sino> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 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] sde2[3] 2097088 blocks [5/5] [UUUUU] md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4](S) 2490176 blocks [4/4] [UUUU] unused devices: <none>Tu crois que je peux rebooter ?
C'est bizarre qu'il n'y ait pas de md2 non ?
C'est pas bizarre que sde (disque de spare) soit intégré dans les md ?
0 -
J'ai commencé avec un DS106e, puis DS211, Puis DS412+ et maintenant ds1515+ ce qui explique peut être cet historique...
Est-ce que c'est risqué cette commande ?
Pour le moment, j'ai compris que mes données n'étaient probablement pas impactées suite à une perte de configuration du RAID.
Je comprends que la commande :
mdadm --assemble --scan --verbosecherche à reconstruire le paramétrage du RAID,
Si la nouvelle définition du raid ne correspond pas à ce que cela était, est-ce que cela ne risque pas de mettre tout en vrac ?
Est-ce que la commande peut juste proposer et ne pas définir la nouvelle configuration ?
Est-ce que je dois espérer une aide du support SYNOLOGY et dans ce cas attendre un peu avant de tenter cela ?
0 -
En complément, voici le log de dmesg si cela peut aider :
Je n'avais pas vu la réponse avec l'historique de mes disques.
Au départ, j'avais
1) 2 disques de 2 To
2) puis j'ai ajouté 2 disques de 3 To
3) Puis j'ai remplacé les 2 disques de 2To par 2 disques de 4To.
Au final,j'ai 4 + 4 + 3 + 3
ce qui me donnait effectivement environ 10To utilisables et 4 To pour la sécurité.
0 -
0
-
Sino> zcat /var/log/messages.1.xz gzip: /var/log/messages.1.xz: not in gzip format
J'ai essayé avec ça sans succès non plus :
Sino> tar xvfJ /var/log/messages.1.xz -C /tmp tar: This does not look like a tar archive tar: Skipping to next header tar: Exiting with failure status due to previous errors
0 -
Pour le log, quand je tape cat /var/log/messages, il ne me donne plus que quelques lignes qui ne sont pas intéressantes ...
je ne sais pas pourquoi le reste des logs n'est plus affiché
Voici pour les sfdisk
Pour le fichier de log, en fait, il a dû être archivé.
Je pense que les messages sont dans le fichier : /var/log/messages.1.xz
---
J'avais des périphériques USB branchés sur mon NAS (clefs Zwave + onewire). Je viens de les retirer. Je ne sais pas si cela peut avoir un lien.
Est-ce risqué de redémarrer dans cette situation ?
0
Crashplan Sur Synology Ds214 ?
dans Logiciels Compatibles
Posté(e)
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.