Mic13710

On ne vous demande pas où vous habitez, ni de décliner votre identité ou si vous mangez du foie gras tous les midis et du caviar à la petite cuillère le soir. simplement de décrire vos connaissances, votre matériel informatique, votre ou vos nas. Rien de personnel qui puisse compromettre votre vie privée. Comment croyez vous que le cloud puisse gérer les versions et vous permette de retrouver un fichier effacé s'il n'y a pas un endroit où sont stockées ces informations ? Tout ça se passe dans un fichier caché nommé @Cloudstation qui peut très vite devenir imposant si des données lourdes sont traitées dans le cloud. A supposer que vous ayez mis des films ou des photos ou tout autre fichier dans votre cloud lorsque votre nombre de versions n'était pas à 0, tous ces fichiers sont conservés sous un format propriétaire (illisible directement) dans ce fameux dossier. Et même si vous les supprimez du Cloud, ces fichiers restent enregistrés dans le dossier. Voila pourquoi, l'espace utilisé ne varie pas tant que vous n'aurez pas supprimé les historiques. Regardez aussi au niveau de vos corbeilles parce que votre espace fantôme peut très bien venir de là.

Je rajouterais que même si on passe le nombre de versions à 0, cela ne modifie pas les versions antérieures. Et donc le fichier caché reste en l'état. Il faut aller dans Cloud Station pour nettoyer le contenu de ce dossier. Et comme mes petits camarades l'ont oublié, je fais passer le message : il existe un forum dédié aux présentations pour que les nouveaux entrants nous parlent un peu d'eux. Merci d'aller y faire un tour, certains y sont sensibles.

Merci pour le retour, mais inutile de le répéter sur tous les sujets de volume planté du forum. Je déplace dans la section tutoriels et je supprime dans les sujets concernés.

C'est très simple. JBOD ou RAID0 même combat. Vous ne pouvez rien faire. Ni rajout, ni extension, ni remplacement. La seule solution est de supprimer le ou les groupes concernée(s) (ce qui de facto vous fait perdre les données) et de les recréer. Donc, si vous voulez transférer un disque d'un NAS vers un autre, ce sera sur les deux NAS qu'il va falloir supprimer. Quand on dit que ces deux formats ne sont pas une bonne idée... La meilleure solution pour transférer vos données est d'utiliser Hyperbackup qui vous permettra de restaurer vos données à l'identique et la majeure partie des paramètres. Si vous avez un DD externe suffisamment costaud, vous pouvez faire vos sauvegardes HB dessus et les restaurer à partir de ce même DD. Bon courage.

Que ça fonctionne est déjà une performance en soit car à ma connaissance seules les Freebox permettent le looopback (votre dernière description). La meilleure solution consiste à séparer les zones WAN et LAN en utilisant le serveur DNS du NAS. Vous trouverez un tuto de Fenrir dans le forum Tutoriels

Deux noms de domaine sur la même racine ou deux noms distincts ? pourquoi pas ? Si Hitman_11 veut deux URL distincts pour ses NAS, c'est une solution. Perso, j'ai deux ndd, un chez Gandi et un autre chez OVH qui pointent tous les deux sur mon IP publique. On peut en avoir autant qu'on veut finalement. Pour le reverse proxy, c'est oui. Chez OVH, vous redirigez le ndd2 vers l'IP publique (DynHost ou enregistrement A). Dans le reverse proxy, vous redirigez les ndd2 vers les différents services du nas2 (par exemple video.ndd2 vers le port http de video station, audio.ndd2 vers le port http d'audio station, etc....)

Belle présentation. Bienvenue dans la communauté. Le NAS est un excellent choix. Je suis moins certain pour les disques car faire du stockage de données, du cloud, de la vidéo surveillance, de la virtualisation plus d'autres paquets qui ne manqueront pas d'être rajoutés par la suite, il me semble que vos 2To (probablement en SHR) seront très vite occupés.

Qui vous a dit qu'il fallait faire une redirection dans le routeur ? christophe2836 vous a parlé du reverse proxy. Dans le reverse proxy du NAS1, il faut faire une règle pour rediriger le port 443 du nom de domaine nas2.votrendd (nas2 étant pris à titre d'exemple) vers le 5000 de l'ip 192.168.x.x du NAS2. Lorsque vous entrerez https://nas2.votrendd depuis l'extérieur, le routeur redirigera la requète sur le NAS1 et le reverse proxy du NAS1 renvera la requete vers le port 5000 du NAS2 ce qui vous connectera au DSM du NAS2

Attention, le dynhost s'apparente à un enregistrement A. Il doit donc être la tête du nom de domaine que vous renvoyez vers votre IP publique et celle que vous utiliserez dans la zone pour créer vos CNAME. par exemple : DynHost : toto.fr (son IP sera mise à jour par le DDNS du NAS) CNAME xxx.toto.fr utilise le ndd du DynHost pour créer un ndd qui pointera sur l'IP enregistrée dans le DynHost. Vous ne pouvez pas mettre un DynHost avec une adresse nom.toto.fr et créer des CNAME en xxx.toto.fr. Dans ce cas, vos CNAME devront être en xxx.nom.toto.fr

Est-ce que vous avez paramétré le DynHost chez OVH et est-ce que l'adresse du DynHost correspond à celle que vous utilisez pour le DDNS ?

Un petit tour par là pour commencer c'est très apprécié et ça met de l'huile dans les rouages. Vider les corbeilles peut-être ?

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

C'est le mail que vous avez renseigné sur ovh et le mdp est celui qui vous permet de vous connecter à ovh.

Non. C'est un disque en RAID SHR. Il faut passer par une distri Linux (Ubuntu par exemple), puis installer mdadm (logiciel de raid) et lvm2 (couche multi-raid). Il y a un tuto pour ça : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC Vous pouvez fermer l'interface de DSM, pas de problème. Le NAS sait très bien travailler tout seul. Inutile de le surveiller il se débrouillera aussi bien sans vous.

C'est normal. La construction d'un groupe peut prendre plusieurs heures. Par contre, prenez garde aux secteurs défectueux. Ils peuvent poser des problèmes lors de la construction et à terme des dysfonctionnements. Après la création du groupe, faire un test SMART étendu pour commencer.

L'accès aux dossiers cachés se fait uniquement par ssh ou telnet via une console. Si vous ne maitrisez pas les lignes de commandes, mieux vaut éviter. Faites un transfert de vos données des 4To vers les 6To (je suppose que ce n'est pas la place qui manque). Utilisez la fonction de déplacement dont j'ai parlé plus haut. Quand c'est fait, vous sortez les deux 4To et vous les formatez sur un pc (formatage rapide), puis vous les réinstallez pour recréer votre groupe et votre volume. Vous faite l'opération inverse pour les dossiers transférés précédemment. Les 4To étant votre volume 1, les paquets s'y trouvent par défaut et seront alors éliminés, ce qui résoudra votre problème. Il va falloir ensuite réinstaller tous les paquets.

Les paquets sont installés par défaut sur le volume 1. Vu la méthode employée, vous avez probablement cassé des processus, ce qui cause les erreurs sur les paquets. Non, les paquets n'occupent pas 1To. Comme je l'ai dit, ce sont les dossiers cachés qui occupent l'espace. Ces dossiers sont gérés par les paquets mais peuplés par les données. Pour pouvoir supprimer un volume, il faut d'abord arrêter les paquets à partir du gestionnaire des paquets. Pour les données restantes sur les 2To, si ce sont des dossiers partagés, vous pouvez tout simplement modifier leur emplacement vers l'autre volume directement à partir du Panneau de configuration - Dossiers partagés. En modifiant le volume d'emplacement, le dossier et son contenu seront transférés. Il faudra attendre la fin du processus.

Ce dont je parlais c'est de la restauration des données à partir d'un dossier .bhk situé sur un disque externe. Pour ce qui est de la migration d'un dossier .bhk, c'est aussi possible. Si vous copiez un dossier toto.bhk de votre DD externe dans le dossier de sauvegarde du NAS cible, vous pouvez recréer une tâche dans Hyperbackup du nas de départ en vous reconnectant sur une tâche existante qui pointe vers le dossier toto.bhk. Toutes les versions qui existent dans ce dossier sont reprises à l'identique par Hyperbackup et seront prises en charge dans Hyperbackup Vault dès la première mise à jour de la sauvegarde.

Sur ce forum, on aime bien que les nouveaux arrivants passent par la section des présentations. Ca permet de mieux vous connaitre, connaitre votre matériel et savoir quel est votre niveau. Effectivement vous n'avez pas du tout suivi la bonne méthode pour effectuer votre migration. C'est probablement la pire qu'il m'ait été décrite. C'était avant d'agir qu'il aurait fallu venir nous voir. Maintenant, il est trop tard. Ce qui reste sur vos disques correspond à des dossiers cachés de certains paquets comme Cloud Station (ou Drive), download station et autres. Si vos données sont sauvegardées et que vous pouvez les restaurer, vous pouvez tout simplement supprimer votre volume puis le recréer. Cette opération supprimera tout le contenu des partitions de données. Le formatage des disques est inutile.

Il est tout à fait possible de restaurer des fichiers hyperbackup à partir d'un disque externe. Sur Hyperbackup du NAS distant, vous cliquez sur le bouton de restauration des données. Dans la page qui s'ouvre vous cliquez sur "Restaurer à partir des référentiels existants", puis vous choisissez Dossier local est USB. La suite est évidente.

Vous confondez volume et groupe. Vos disques constituent un groupe sur lequel vous pouvez montez un ou plusieurs volumes. Je ne connais pas le paquet en question.

Le changement du nombre de versions n'a aucune incidence sur les versions précédentes et donc sur la taille de la base. Il faut nettoyer la base pour retrouver l'espace, mais ça suppose qu'on tire un trait sur les versions précédentes et les fichiers supprimés.

Vous pouvez tout monter en une seule fois. C'est le mieux car chaque rajout fait travailler les disques. Si tous vos disques sont OK, ça ne posera pas de problème. L'ordre des disques importe peu, mais il est plus logique de monter les disques de manière ordonnée, du plus petit au plus grand par exemple. Votre SHR construira un RAID5 avec vos 3x4To + 4x4To pris sur les 8 et 10To (soit 24To de stockage), un autre RAID5 de 4x4To avec le reste des 8To et 4 autres To sur les 10To (soit 12To de stockage), et enfin un RAID1 de 2x2To sur le solde des 10To (soit 2To de stockage). Au total vous aurez un groupe de 38To, ce qui est conforme au résultat du calculateur. https://www.synology.com/fr-fr/support/RAID_calculator?hdds=4 TB|4 TB|4 TB|8 TB|8 TB|10 TB|10 TB Ce que vous ferez d'un aussi gros stockage vous regarde, mais de mon point de vue une telle capacité sur un seul groupe n'est pas une bonne chose car plus la taille augmente, plus les risques d'erreurs augmentent avec des conséquences désastreuses sur la viabilité du groupe. Si vous souhaitez un aussi gros groupe, il faudrait passer au SHR2, mais ceci nécessiterait de rajouter 2x10To supplémentaires.

La raison en est simple. Le SHR est un raid hybride. Le premier RAID qui sera constitué sera fait avec le plus petit des disques en place. Supposons que les premiers disques soient 1x2To et 2x4To, le SHR va créer un RAID5 avec le 2To et 2To des 2x4To. Il va ensuite créer un RAID1 avec les 2To restants des 2x4To. Par la suite, tout ajout de disque se fera par rapport à ces deux raid. Admettons qu'on rajoute un 6To, le SHR va d'abord rajouter 2To au premier RAID5, puis il va rajouter 2To au RAID1 et le transformer en RAID5. Les 2To restants ne seront pas exploités. Il faudra un autre 6To pour pouvoir les utiliser avec 2To rajoutés au premier RAID, 2To au deuxième et la création d'un RAID1 avec les 2To restants sur les 2x6To. Si on rajoute un 3To à ce groupe, seulement 2To seront utilisés avec le premier RAID, le To restant ne pouvant pas être associé avec un autre RAID ne sera pas utilisé. Il faudra un autre 3To pour à nouveau créer un RAID1 de 1To. En suivant cette logique, on peut très bien rajouter un 2To qui sera automatiquement associé au premier RAID.

C'est pas tout à fait exact. Le SHR exige que le nouveau disque soit au moins de capacité égale au disque le plus petit ayant constitué le SHR d'origine. Je m'explique. Si un SHR a été initialement constitué de disques de 2To, puis augmenté en remplaçant ces disques par des 4To, il sera toujours possible ultérieurement de rajouter des 2To dans le groupe, même s'il n'y en a plus physiquement installé.