gaetan.cambier

dans tous les cas, raid ou jbod, si un disque lache, tu perd toute tes données

Ssh via putty sous windows

pensait qu'il y avait un reverse proxy ... apparemment, j'ai mal lu ou encore une fois lu a moitié, oui en entreprise, faut deja passé par un port standart pour avoir une chance que çà passe

evidemment que ce sera pareil, pour l'initialisation du nas, le dsm pourrait fonctionner avec 128mo de ram, il a pas besoin de + c'est toute les application après que l'on ajoute qui prennent de la ram, et la ram est aussi utilise en cache, mais ici, rien de tout çà

dans tous les cas, faut une sauvegarde, bon, c'est vrai peu de gens comprennent ... jusqu'à les voir pleurer sur les forum car ils ont perdu des données car meme sans crash disk, on backup est utile : dernièrement, çà m'a permis de recuperer le .htacces de mon site qui avait été modifier par un plugin. bon, c'était rien de grave si j'avait du le recréer, mais faire un restore du fichier m'a pris 15 seconde pour revenir au bon fichier, c'est appreciable

alors c'est simple : on vérifie le raid avec la commande suivante : cat /proc/mdstat on trouvera 3 matrice raid, et md2 est celle du volume1 dans md2, on verra des partition, en théorie sda5 et sdb5 pour supprimer le disk 2 on travaille sur sdb5 on declare le disque defaillant : mdadm /dev/md2 -f /dev/sdb5 le nas se met à bipper, c'est normal (volume dégradé) on ejecte le disque du raid : mdadm /dev/md2 -r /dev/sdb5 on passe le raid de 2 disques à 1 mdadm --grow --raid-devices=1 --force /dev/md2 on arrive la à un volume SHR sans protection de donnée, et le nas le considère normal et a areter de bipper et on peut créer un nouveau volume sur le disk2 qui est dans le statut "initialisé" temps total de l'operation : moins de 5 minutes en prenant son temps

heu, et sinon, repasser le volume 1 de 2 disques à 1 sans faire toute ses manipulations qui vont prendre des heures, c'est à dire passer une ligne de commande pour repasser le shr à son etat initial : c'est fait en 5 minutes, et c'est pas compliqué, car passer tout d'un volume à l'autres, c'est .... long

Non, chez toi c'est noté /var/@tmp qui n'existe donc pas

Ben, ta ligne peut pas démarrer vu que le dossier top que tu as spécifié n'existe pas

bon, c'est assez illisible, mais j'ai trouve le problème : à la fin de la 1° ligne, tu modifie : /var/@tmp par : /volume1/@tmp ps si crashplan n'est pas installé sur le volume 1, faut modifier par le bon volume et tu redemarre CrashPlan

@Moonface : tu peux taper cette commande en ssh et donner le retour : cat /usr/local/crashplan/bin/run.conf

Oui tu peux le mettre. L'avantage de haproxy, c'est que tu ne risque pas que Synology casse ta config après une update

q1 : le dsm supprimera tout automatiquement si necessaire q2 : faut se connecter en root et pas en admin

Il est formaté en quoi ?

verifie la t° cpu, et verifie si le nas est propre sur les entrees d'air

bah, à ton travail, tu as p-e un proxy qui intercepte le flux ssl (ssl-bump) et qui empeche tout simplement de se connecter à un site qui a pas un vrai certificat c'est simple de savoir si c'est cela, tu te connecte à un autre site qui utilise le ssl, et tu verifie le certificat pour voir de qui il viens, en cas d'interception ssl, tu n'aura pas les meme resultat

c'est plus un problème de raid avec une ecriture qui s'est pas ternimée vu la panne de courant il me semble pourtant que les onduleur servent à palier ce problème ... faudrait lancé un check du raid : echo check /sys/block/md0/md/sync_action echo check /sys/block/md1/md/sync_action echo check /sys/block/md2/md/sync_action après, faudra verifié si il y a un problème ici : cat /sys/block/md0/md/mismatch_cnt cat /sys/block/md1/md/mismatch_cnt cat /sys/block/md2/md/mismatch_cnt si c'est pas = 0, faut lance la reparation du raid

vaut mieux suivre ceci : http://pcloadletter.co.uk/2012/01/30/crashplan-syno-package/ + simple qd meme ps: il y aura un problème après suite à update de crashplan, mais ca se resoud facilement

disont que l'ecriture de 0, si le disque ne genère pas d'erreur, on considère que c'est ok le badblock va normalement vérifier les données écrite --> il va faire + travailler le disque mais un bon disque ne doit pas lacher pour cela il risque de trouver des secteur defectueux plus tot après tout, si le disque a un problème, autant qu'on le voit direct pour faire un RMA car un fois qu'il est utiliser, on va hésiter à faire l'echange

ca aurait été une architecture que l'on trouve facilement (moi dans mon nas j'ai du x86 ) on le trouve avec google, mais là, c'est très dificile, ca risque de prendre plus de temps à chercher qu'a compiler

c'est sur que j'ai posé une question clair : est-ce un dossier crypté, et j'ai encore eu une reponse de politicien : du ni oui ni non si c'était simplement un dossier partagé non crypté, je voit pas trop le problème vu que l'admin a accès à tous les dossier donc pour moi, çà doit etre un dossier crypté mais sans reponse claire, c dur de savoir

tu peut très bien utilisé cette commande qui est destructive, je la donne pas, car si quelqu'un passe sur le forum en lisant à moitié, c'est la catastrophe si les disque contiennent des données. avec l'option -nvs, aucun risque pour les donnée, mais autant utilisé sur un système partitionné la commande e2fsck -cf /dev/sda elle reparera le système de fichier en meme temps

non, c'est en standard dans le dsm !!!

pourquoi ? ca fonctionne sur tout les nas badblock est inclu dans tous les nas vu que c'est intégré au dsm : /sbin/badblocks

C'est qd même mieux d'utiliser badblock pour tester un disque badblocks -nvs /dev/sda