Fravadona

en RAID1 (mais pas en SHR) c'est possible lors de la creation du volume en définissant la taille voulu, tu la tronques a un multiple de 10Go

Ah, effectivement. Je corrige : D'un autre cote, vu le prix actuel des switchs gigabits 48-ports je conçois difficilement de s'en passer pour interconnecter des switchs 10/100, ca vaut peut-etre le coup d'investir un petit millier d'euros pour un bon switch Giga

Les WD Green ont 2 000 398 Mo utilisable alors que les Seagate n'auraient que 2 000 000 Mo (a priori, car datasheet pas tres precis), et donc les Seagate seraient plus petits (= problème) Vu que tes Seagate sont deja installés dans un NAS tu peux verifier leur taille avec la commande fdisk -l /dev/sda PS: J'ai découvert cette problématique avec des disques de 250Go -> la baie RAID ne voulait pas reconstruire le volume avec les nouveaux disques de 250Go que j'y mettais (car trop petits)... Maintenant je tronque la capacite des disques a des multiples de 10Go, ce qui permet d'utiliser n'importe quel fabriquant/modele en cas de besoin.

L'archi reseau pour ton serveur de fichiers doit etre celle-ci : SWITCH_GIGA ---- NAS (connecté au switch avec autant de liens gigabits que le Nas ET les perfs disque le permettent) / | / | SWITCH_100_1 ... SWITCH_100_7

CentOS 6 prend en charge ext4 oui, ton probleme d'acces vient probablement du RAID qu'il faut reactiver (voir meme reassembler)

Les disques etaient en RAID1 ou bien en SHR ? Sous Linux tu dois commencer par tenter de recuperer les donnees effacees avec extundelete , et si ca ne fonctionne pas alors avec photorec (plus lourd)

Attention les disques ne font peut-etre pas exactement la meme taille; il faut verifier que le nombre d'octets est identique, et s'il ne l'est pas alors il faut tronquer la taille du volume ou utiliser un des "petits" lors de la creation du volume. NB: Pourquoi un SHR et pas directement un RAID5 ?

S'il n'y a pas d'erreurs de lecture sur le disque inititial alors la commande : dd if=/dev/anciendisque of=/dev/nouveaudisque conv=noerror Te donnera un nouveau disque 100% fonctionnel qui pourra etre replacé dans ton RAID0 NB: Bien sur il faut retirer/ajouter les disques avec le NAS eteint pour pouvoir faire le remplacement de maniere transparente

T411 a fait une grosse maintenance ce W-E, je suppose qu'ils ont changé la structure du site et le moteur de recherche. Il ne reste plus qu'a redevelopper le plugin T411 pour DownloadStation...

Pas vraiment d'accord avec cela, pour des RAIDs avec pas mal de disques il vaut mieux avoir : meme modele & meme firmware & lots differents. En fait tous les disques du RAID6 seront sollicités pour la reconstruction, mais c'est vrai que le RAID6 apporte une securite supplementaire par rapport en RAID5. Par contre au niveau de la perf du RAID6 sur un NAS c'est la cata

Ces deux nas n'ont pas la meme architecture cpu, il faut passer par une reinstallation de DSM (procedure de migration)

Il faut peut-etre desactiver "la prise en charge des fichiers hors ligne" au niveau du NAS, et sinon le desactiver directement sur le PC. Pour verifier que c'est bien du a cela regardes combien occupe le repertoire C:WindowsCSC

Tu as un SHR ?

Je ne suis pas sur que les logiciels de clonage vont reussir a prendre en charge un disque Syno (c'est un peu le boxon dessus). Si le disque de remplacement est du meme modele alors tu peux utiliser la commande dd sous Linux pour copier tout le disque a l'identique. Ton probleme sera de pouvoir "garder" ton disque initial sans l'envoyer a WD.

En fait tout depend des logiciels qui utilisent l'espace sur C. 50 Go pour Seven c'est un peu limite mais ca devrait pouvoir passer (si tu n'installes pas de jeux et ne telecharge pas dessus)

Si tu fais comme Syno le preconise ton volume resultant restera avec le nom Volume2 et ta bibliotheque iTunes aura disparu

Je suppose que tous ces switchs 10/100 sont interconnectées par un switch gigabit. Le NAS devra être branché a ce switch gigabit, et de preference avec une aggregation de liens.

Non bien entendu, mais n'as tu pas un Linux ou un XP pour tester ?

Tu y vas un peu fort, on repondait juste a sa question OpenLDAP possede un mode mirroir qui lui conviendrait tres bien, mais je ne pense pas les Syno prennent en charge cette option, et vu que les modifications directes de fichiers de conf sont generalement écrasées lors des mises a jour ou des reboots ... Avec DRBD, la replication temps reel en mode block n'est pas envisageable sans une ligne réseau fiable (et suffisante), car quand le site secondaire devient injoignable les acces disques du site principal sont bloqués (apres que le buffer d'ecriture local soit totalement rempli). Les solutions propriétaires demandent aussi ce genre de liaison car quand le buffer local devient insuffisant il faut resynchroniser tous nos petaoctets depuis le debut.

As-tu essaye avec un partage SMB1 ?

Pour proteger le NAS contre qui ? Les enfants ?

Plus rien dans l'explorateur de fichiers cela voudrait dire que Windows tente tout de meme d'acceder a ton NAS via SMB2, c'est surtout les registres Windows qu'il faut editer (puis redemarrer) plutot que le NAS. Pour qu'une modification du fichier smb.conf soit prise en compte il faut desactiver le partage Windows, editer le fichier, demarrer le partage Windows.

Peut-être un problème lié a la version de SMB ?

En SMB1 et sans jumbo frames ca ne change rien (reboot requis pour etre sur) ? L'utilisation a 100% du CPU se fait pour une copie du PC vers le NAS ainsi que du NAS vers le PC ?

Quel services doivent etre dupliqués ? Pour les utilisateurs -> mettre en place un annuaire LDAP sur chaque NAS et synchroniser leur contenu lors des modifications Pour les droits sur les partages -> je pense que la synchronisation/sauvegarde du fichier smb.conf devrait suffire Contenu des volumes -> un rsync regulier pourrait faire l'affaire