Mic13710

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.

Pas de quoi. L'important c'est que votre problème soit résolu

Aie ! la faute à Lucien77 !

Un autre candidat au top ten

Je pense tout simplement que votre cloud est clairement très mal utilisé. Le dossier de suivi pèse 1.4To. Ce dossier assure le suivi des versions et permet la récupération des fichiers qui ont été supprimés. En règle générale, on considère que ce dossier pèse approximativement la somme de tous les dossiers intégrés à CloudStation. Ce qui indiquerait que l'ensemble de vos dossiers CloudStation pèserait 1.4To. Vu que votre stockage ne fait que 1.8To, il est impossible d'avoir un cloud de 1.4To. Au pire il ne pourrait faire que 1.8 - 1.4 = 400Go, ce qui est pas mal pour un Cloud. J'en conclus deux choses : que vous avez un nombre important de fichiers et/ou beaucoup de gros fichiers qui ont transité par CS et qui n'y sont plus mais dont la trace existe encore dans le dossier de suivi, que vous faite une utilisation inappropriée de CS. En effet, je soupçonne fortement que vous avez mis dans CS tout et n'importe quoi, et dans ce n'importe quoi il y a des fichiers multimédia (vos photos par exemple). CS n'est absolument pas une solution pour les fichiers de ce type. Il y a des applications dédiées qui font très bien le job (Video, Audio, Photo Station), autant les utiliser. CS ne devrait être utilisé que pour des fichiers de travail appelés à être modifiés dans le temps (tableaux, traitement de textes, bases de données etc, essentiellement de la bureautique quoi), ou des fichiers qui sont consultés fréquemment (.pdf par exemple). Mon conseil serait dans un premier temps de supprimer le paquet cloudstation. Ceci va permettre de libérer la place occupée par @cloudstation. Il faudra attendre quelques temps pour que toute la place soit libérée (1.4To, ce n'est pas rien). Vous réinstallez CS, mais cette fois vous n'y mettez aucun dossier multimédia. Vous utilisez les paquets multimedia pour gérer vos fichiers multimedia.

Si vous utilisez ou avez utilisé CloudStation et/ou DownloadStation, ne cherchez pas plus loin, il y a sûrement des dossiers cachés volumineux. Pour voir où sont passée les données, connectez vous en SSH sur votre nas et lancez la commande suivante : du -h -d 1 /volume1/

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.

@PiwiLAbruti tu as oublié de mettre dans la liste celui du 3 octobre découvert par Lucien77 :

Et si vous commenciez par consulter les tutos avant de poster ? Il y en a un très bien fait ici. Je verrouille le sujet car les réponses sont disponibles dans le tuto.

Non seulement passer le nombre de version à 0 pour ne plus avoir de suivi (à mon sens c'est une erreur mais pourquoi pas), mais il faut aussi se connecter avec chaque compte utilisateur ayant des droits Cloudstation pour avoir accès aux historiques et les effacer.

Qu'est ce qui vous fait dire que les données sont toujours sur le volume 1 ? Pour info, si vous avez déplacé un dossier d'un volume à un autre, vous ne pouvez pas le voir à partir de file station. Il sera toujours présent au même endroit dans file station, comme s'il n'avait pas bougé. En effet, Linux considère les disques comme un tout. Il n'y a qu'un seul stockage même si les données sont physiquement sur des disques différents. Edit : Si vous voulez vraiment savoir où sont passés vos dossiers, vous pouvez le faire en ligne de commande à partir d'un terminal (putty) en ssh avec la commande suivante : du -h -d 1 /volume1/ du -h -d 1 /volume2/ etc.. jusqu'au dernier volume Ces commandes vous donneront la taille physique et le nom de chaque dossier du volume 1, puis du volume 2 etc... Ainsi vous saurez où est passé votre dossier partagé.

La taille de votre Cloud ne présage en rien la taille du dossier de suivi. @cloudstation garde les traces de tous les fichiers que vous avez mis dans le Cloud. S'ils ont été supprimés, vous pouvez les retrouver dans l'historique. Si vous y avez mis beaucoup de fichiers à un moment donné ou des fichiers volumineux que vous avez ensuite supprimés ou effacés, ils sont toujours dans l'historique. C'est ce qui explique la taille relativement importante de votre dossier @cloudstation. Maintenant vous savez que le fautif c'est @download. Quoique le plus gros et de loin soit la musique.

Il faut aller dans le gestionnaire de stockage menu HDD/SSD, Planificateur de test. Pour le reste, vous devriez savoir faire.

pour le savoir, passez cette commande en mode terminal pour lister les dossiers et voir ce qu'ils occupent : du -h -d 1 /volume1/

Service d'application Synology Synology Inc. Synology Application Service propose un cadre permettant d'enrichir les fonctionnalités et les services des paquets Synology packages, notamment les notifications push et les paramètres des profils. Grâce à Synology Application Service, Il est possible de partager des configurations cohérentes dans différents paquets Issus de la description des progiciels Synology. J'ai vraiment pas l'impression que ce soit un truc très utile.

@Fenrir par défaut c'est 32 mais on peut mettre la valeur à 0 ce qui bien entendu supprime la possibilité de retrouver un fichier. Le dossier @cloudstation est influencé par le nombre de versions bien sûr, mais ce ne sont que les modifs qui sont enregistrées. Comme généralement elles sont légères, l'augmentation n'est pas très importante même au bout de 32. Et puis le dossier est compressé ce qui permet de gagner de l'espace. Raison pour laquelle à la version 1 (création du Cloud) ce dossier est bien moins lourd que l'ensemble des fichiers. A titre d'exemple, mes dossiers CS avec 32 versions sont les suivants : Ensemble des dossiers CS : 53.7Go @cloudstation : 46.4Go soit 86% de l'ensemble des dossiers. La dedans, il y a beaucoup de fichiers avec leurs 32 versions.... Edit : On s’aperçoit très bien que si on s'amuse à peupler CS avec des fichiers multimedia qui sont déjà optimisés, non seulement ça ne sert à rien du point de vue utilisation mais en plus ça fait gonfler @cloudstation d'un ratio de 1 puisqu'il n'y a rien à espérer côté compression des données. A l'inverse, des fichiers type Office ou des fichiers .TXT par exemple sont propices à la compression et donc moins gourmands du côté de @cloudstation, même avec un nombre de versions maxi.

Pour ne voir que le home utilisateur, il faut supprimer les permissions homes. Ca peut se faire soit au niveau du groupe users et à ce moment là tous les utilisateurs seront concernés et il faudra ensuite les remettre pour ceux qui ont la permission, soit au niveau de chaque utilisateur. Vous pouvez aussi créer un groupe spécifique pour les utilisateurs qui ont seulement accès au répertoire commun et vous basculez vers ce nouveau groupe les utilisateurs déjà inscrits. Ca vous évite par la suite d'avoir à redéfinir des droits particuliers pour chaque nouvel utilisateur.

Je réponds à votre question par une autre question : Quand votre verre est plein à ras bord, vous pouvez encore le remplir ? Si votre stockage est à 100%, c'est que tous les clusters sont occupés. Donc non, vous ne pouvez plus rien y mettre. Si vous avez CloudStation et que le versionning est activé, il faut savoir que l'espace occupé sur le disque est environ le double de l'ensemble des dossiers Cloud. Si tous vos dossiers Cloud pèsent 500Go, l'espace occupé sur le disque sera de 1To environ. Cet espace supplémentaire est occupé par un dossier caché qui permet de retrouver les versions antérieures des fichiers ou de récupérer des fichiers supprimés.

BTRFS uses copy-on-write feature, meaning that when you edit a file BTRFS does not delete previous data, but writes changes to the new place instead. Because of this, file fragmentation is possible, slowing down file copying. The same copy-on-write feature also leads to another difficulty - the recovery time will be quite long, since the software has to analyze different versions of files and other metadata to choose the latest one. However, in the end the recovery quality tends to be fairly good. En clair, il peut y avoir des données éparpillées qui correspondent à différentes versions d'un même fichier. La difficulté c'est de retrouver les bons morceaux de les associer pour retrouver l'intégralité du fichier.

Salut CoolRaoul, Je ne sais pas si ça peut t'aider, voici les mêmes commandes que Fenrir sur mon 214+ Bipbip> ps | grep -i audio 12532 root 80224 S < /var/packages/AudioStation/target/sbin/synoaudiod 12547 root 81444 S < /var/packages/AudioStation/target/bin/pulseaudio --r 12567 root 13288 S < /var/packages/AudioStation/target/sbin/synorcd 25779 root 4008 S grep -i audio Bipbip> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 1005 Oct 16 19:00 /tmp/AudioStation/player.list.json Bipbip> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 1005 Oct 16 19:01 /tmp/AudioStation/player.list.json Bipbip> ls -l /tmp/AudioStation/player.list.json -rw-r--r-- 1 root root 1005 Oct 16 19:02 /tmp/AudioStation/player.list.json Bipbip> stat /tmp/AudioStation/player.list.json File: "/tmp/AudioStation/player.list.json" Size: 1005 Blocks: 8 IO Block: 4096 regular file Device: fh/15d Inode: 15967 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2016-09-05 10:29:15.000000000 Modify: 2016-10-16 19:02:30.000000000 Change: 2016-10-16 19:02:30.000000000 Bipbip> top Mem: 1018780K used, 14976K free, 0K shrd, 46088K buff, 488200K cached CPU: 0.0% usr 4.5% sys 0.0% nic 95.4% idle 0.0% io 0.0% irq 0.0% sirq Je ne vois pas ce que je devrais voir donc je ne vois pas où il peut y avoir un problème.

A essayer. Il semblerait qu'il soit capable de retrouver mais surtout restaurer des données en btrfs.

C'est pourtant clair. Les 2 PC sont reliés au NAS. Ce réseau n'est pas connecté à internet. kayakfreestyle veut pouvoir sauvegarder les données du NAS sur un autre NAS externalisé en utilisant la deuxième RJ45.

Les deux ports RJ45 sont prévus pour faire de l'agrégation de liens. Ce que vous voulez faire revient à connecter le NAS sur 2 réseaux séparés. Je crois bien que si sur le papier une utilisation sur 2 réseaux distincts est possible, la réalité se heurte à des difficultés pratiques qui rendent les paramétrages compliqués. Il y a eu un post récent à ce sujet sur le forum. Ne serait-il pas plus simple d'installer un routeur paramétrable qui permet de bloquer les accès internet pour certains postes ?

Non pas tous. Uniquement les NAS milieu/haut de gamme. Pour la récupération, hormis le lien que je vous ai donné qui ne travaille que sur les fichiers existants, il n'y a pas de moyen officiel de le faire. Un NAS est seulement un moyen de stockage. En aucun cas il ne sécurise les données et je ne sais pas ce qui vous fait croire le contraire. Synology nomme à tord le RAID une sécurisation des données alors qu'il ne s'agit que d'une continuité de service. Et donc en aucun cas un NAS vous dispense de faire des sauvegardes. La logique veut que la récupération des données effacées se fasse à partir de la poubelle si vous l'avez activée ou de la sauvegarde en dernier recours. Ce qui est effacé est effacé et il est très difficile de récupérer des données effacées sous linux que ce soit en ext ou en btrfs. Si vous réussissez à le faire, tant mieux pour vous, mais ce n'est pas une fonction supportée. Le message d'ufs explorer indique seulement qu'il peut vous aider à retrouver le système de fichier qui se trouvait sur le disque avant formatage. En aucun cas il s'agit de récupération de données. BTRFS est bien trop récent sur nos nas et je ne connais pas de système capable de récupérer des données sur des disques de ce format. Peut-être que d'autres intervenants ont des solutions à proposer.

Je viens de regarder ufs explorer. Effectivement, il peut travailler avec du btrfs mais ne peut pas y faire grand chose : Btrfs: data access and failed RAID recovery only Juste la récupération du RAID. Pas de récupération de données.