Mic13710

@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.

SHR c'est un RAID à la sauce plus ou moins Synology. Ca n'a rien à voir avec le format du disque. Rien ne change du point de vue adressage du RAID, seulement vous risquez de ne pas pouvoir lire les fichiers à cause de leur format BTRFS. Je ne connais pas la procédure de lecture d'un disque RAID avec un MAC et d'ailleurs il ne me semble pas que Synology ait fait un tuto pour ça. Le seul tuto que je connaisse c'est à partir d'un PC à l'aide d'une distribution Linux (Ubuntu). L'accès à la partition de donnée reste identique que ce soit EXT4 ou BTRFS. Reste à savoir si Ubuntu sait lire une partition BTRFS.

Si vos disques ne sont pas issus d'une migration d'un NAS plus ancien, votre partition donnée est en BTRFS. Seules les partitions système et swap sont en EXT4. Je ne sais pas si le BTRFS est lisible sur un PC Linux ou sur un MAC. Le BTRFS travaille avec des snapshot. Peut-être que par ce biais et à l'aide d'un logiciel qui sait lire le BTRFS, vous pourriez récupérer votre dossier.

Non, c'est bien dans volume. C'est le volume qu'on doit reconstruire. Dans ce menu, il doit y avoir le bouton "Gérer" accessible. De là on peut demander la réparation du volume.

Qu'est ce que vous appelez un "secure erase" ? C'est dans DSM ?

Salut Fenrir, non pas de café pendant les pannes de courant . Mais je pourrais... Je sais que ça peut paraître surchargée. En réalité, il n'en n'est rien. L'onduleur est tout à fait capable de gérer tous les consommateurs.

Salut StephanH. Cette solution ne serait applicable qu'aux nouveaux fichiers, pas aux anciens qui sont déjà dans @cloudstation. Vu la taille de ce dossier dans le cas présent, le nettoyage par le vide reste la meilleure option. Pour la version CS que j'ai sous DSM5.2, il n'y a pas de possibilité de choisir des nombres de versions différents par dossier. C'est du tout ou rien. Si on choisi 0, on perd le versionning qui est tout de même un des gros intérêts du cloud. Est-ce que la version sous DSM6 permet de faire des choix différents par dossier ? J'ai tout de même un doute.

Pas de quoi . Désolé, je ne réponds pas aux demandes par MP. Si vous avez d'autres questions, vous pouvez consulter le forum où tout ou presque a déjà été dit, et ouvrir une nouvelle discussion si vous ne trouvez pas de réponse. Bon WE.