Perte données suite erreur de copie de fichier

[totof74]

Bonjour,

J'étais en train de configurer le VPN de mon synology à distance (en SSH) quand j'ai eu besoin d'aller récupérer le fichier openvpn.conf.

Je suis passé en su et pour le rendre visible depuis mon explorateur, j'ai voulu le copier dans un répertoire partagé.

Malheureusement, mes reflexes Windows on prit le dessus, ceci ajouter a des gros lags sur la console ssh, j'ai commis l'irréparable (enfin j'espère pas).

J'ai tapé quelque chose du genre : cp /volume1/jesaispluslerépertoire/openvpn.conf *

Depuis, toutes mes données dans tous mes volumes ont disparues et à la racine de chaque volume, j'ai un unique fichier openvpn.conf.

Curieusement, j'ai pu rebooter sans problème (avant de me rendre compte du problème), et même relancer le proxy SSH.

J'imagine, que je vais devoir en passer par un soft de récupération de fichier, si tant est que ça puisse fonctionner....

PS : je n'ai plus d'accès à la console WEB synology (du moins à distance).

Quelqu'un a-t-il une solution ou des conseils ?

Merci par avance de votre aide...

Totof74

 

Edit : précisions à toutes fins utiles : je suis (étais ?) en DSM5.0 (je crois) 

 

Modifié le 5 janvier 2017 par totof74
précisions

[Fenrir]

Il y a 6 heures, totof74 a dit :

J'imagine, que je vais devoir en passer par un soft de récupération de fichier, si tant est que ça puisse fonctionner....

à mon avis ils ne trouveront rien (ou pas grand chose) pour 3 raisons :

Il y a 6 heures, totof74 a dit :

J'ai tapé quelque chose du genre : cp /volume1/jesaispluslerépertoire/openvpn.conf *

car tu as écrit sur le disque

Il y a 6 heures, totof74 a dit :

Curieusement, j'ai pu rebooter sans problème

car tu as écrit sur le disque

Il y a 6 heures, totof74 a dit :

et même relancer le proxy SSH.

car tu as écrit sur le disque

 

===> désolé, mais à première vu tu es mal barré

Je suppose que tu n'as pas de sauvegarde => passe par une entreprise spécialisée (ça coute un bras et un rein, à toi de voir)

Un conseil tout de même, coupe électriquement le nas, plus il tourne, plus tes chances de récupération diminuent

[totof74]

Bonjour Fenrir,

Et merci de t'être penché sur mon problème.

Malheureusement je t'ai fait perdre ton temps.

Pour une raison que j'ignore, ce qui s'affichait sur la console via SSH était faux... Je ne comprend pas ce qui est responsable de ce problème d'affichage, mais une fois chez moi, j'avais toutes mes données... J'ai juste copié le fichier openvpn.conf dans un certain nombre de répertoires.

Etant informaticien, je suis familier avec les conseils en cas de perte de DATA, et par là même, je savais que mon cas eût été grave et donc que cela ait écrit un peu plus ou un peu moins n'aurait pas changé grand chose car je n'aurai de toute façon pas fais appel à une société de récupération de DATA.

Elles fonctionnent bien pour les entreprises (j'ai déjà expérimenté), mais pour les particuliers, il y en a beaucoup qui font de l'arnaque... Genre, ils ne récupèrent que lorsque c'est récupérable facilement par soft et dès qu'il y a une panne plus grave (ou sur des systèmes autres que FAT ou NTFS) ils disent qu'ils ne peuvent rien récupérer après avoir empoché le montant du devis cependant. Ce qui est faux. C'est souvent récupérable, à condition d'y passer le temps nécessaire et être près à y investir une somme conséquente.

Accessoirement, si, j'ai des sauvegardes, c'est justement ça mon système de sauvegarde, mais bon, j'avoue qu'il y a quelques data non sauvegardées et aussi qu'il assure d'autres fonctions qui elles ne sont pas backupées (DNS, mail, directory, etc.).

Aussi, les données sont réparties sur 4 disques différents dont un consacré uniquement au système, raison qui me fait penser que les disques n'auraient pas été réécris tant que ça par le reboot/l'accès SSH, mais je peux me tromper, linux est peut-être différent de Windows sur ce point.

Bref, plus de peur que de mal, c'est un avertissement sans frais comme on dit ! Je ne comprend toujours pas pourquoi la console ne m'affichait plus rien avec un "ls".

 

Pour que ce post, n'ait pas servi à rien, si j'avais constaté la disparition effective de mes données, quels eut-été la bonne méthode ?

Débrancher le disque et essayer de voir ça sous Windows ? Je suppose qu'il faut un outil pour lire les  Ext4...

Coller ça dans une machine linux ? Quels outils utiliser ?

Merci,

Christophe

 

[Fenrir]

il y a 10 minutes, totof74 a dit :

Malheureusement je t'ai fait perdre ton temps.

Ce n'ai pas grave que j'ai perdu 30sec si toi tu n'as pas perdu tous tes fichiers, je m'en remettrais

En fait en seconde lecture, ta commande n’aurai pas pu écraser tous tes fichiers (et ne l'a pas fait) mais je me suis aussi fié à ton diagnostique (tout avait disparu).

Par contre il est probable que, au choix :

• un des fichiers (peut être dans un sous dossier) l'ait été
• que ton fichier openvpn.conf ait été copié dans un des dossiers
• que des fichiers présent dans le même dossier (là où tu étais) aient été copiés dans certains dossiers

En fait ça dépend d'où tu étais au moment de la commande, des noms de dossiers/fichiers et de leurs dates. Le comportement peut aussi varier en fonction de la busybox (en DSM 5 la commande cp est différente de celle en DSM 6).

Exemple avec le cp de coreutils :

me:~/test$ tree
.
├── 1
├── 2
├── 3
└── dossier

1 directory, 3 files
----------------------------------
me:~/test$ cp /etc/passwd *
----------------------------------
me:~/test$ tree
.
├── 1
├── 2
├── 3
└── dossier
    ├── 1
    ├── 2
    ├── 3
    └── passwd

1 directory, 7 files

Un find avec l'option -mtime devrait t'aider à y voir plus clair.

il y a 14 minutes, totof74 a dit :

je savais que mon cas eût été grave et donc que cela ait écrit un peu plus ou un peu moins n'aurait pas changé grand chose

Il suffit de modifier quelques blocs aux mauvais endroits pour perdre de nombreuses données (en fait ça dépend bcp de la taille des fichiers) alors que si rien (absolument rien) ne bouge sur la surface, les chances de récupération sont proches de 100% (en y passant le temps nécessaire).

il y a 18 minutes, totof74 a dit :

Aussi, les données sont réparties sur 4 disques différents dont un consacré uniquement au système, raison qui me fait penser que les disques n'auraient pas été réécris tant que ça par le reboot/l'accès SSH, mais je peux me tromper, linux est peut-être différent de Windows sur ce point.

Il y a effectivement une grosse différence entre Windows et ... le reste du monde, sous Windows il n'y pas de vraiment (au sens technique) de système de fichiers ni d'arborescence, tout est à plat et l'os ajoute des metadatas pour "simuler" une arborescence. Pour l'anecdote, on doit ça Bill Gates himself, il avait codé son FAT de cette manière pour gagner du temps (quick&dirty), c'était à la fin des années 70.

Le résultat est que sous Windows, l'adressage des lecteurs (disques/partitions/lecteurs réseaux/...) doit se faire en changeant de contexte (c: -> d: ...) ce qui pose de très nombreux problèmes.

Presque tous les autres OS (qui sont presque tous des unix  : linux, mac, android, solaris, aix, ...) on un vrai système de fichiers avec une arborescence, donc tu peux très bien avoir le contenu d'un disque dans un dossier d'un autre disque, voir de plusieurs (on parle de points de montage). Par exemple le dossier /var/log (qui peut très vite grossir) est souvent dans une partition dédiées afin d'éviter de saturer le système, mais /var reste sur la partition principale. Donc dans le cas présent, en fonction des réglages que tu as fait et de l'endroit d'où tu as lancé la commande, tu aurais très bien pu supprimer toutes les données de tous les disques (le fameux rm -rf /*).

<HS>Si tu veux une preuve qu'il n'y a pas d'arborescence sous Windows, c'est facile, créé plusieurs dossiers les uns dans les autres et interdit à tout le monde sauf à toi d'accéder à leurs contenu, puis créé un fichier dans un sous dossier et autorise tout le monde à y accéder. Malgré le fait que personne ne peut "rentrer" dans les dossiers, le fichier sera parfaitement accessible (en l'adressant avec son chemin complet).</HS>

il y a 33 minutes, totof74 a dit :

Je ne comprend toujours pas pourquoi la console ne m'affichait plus rien avec un "ls".

Surement un effet secondaire de la petite montée d'adrénaline que tu as du avoir ou plus vraisemblablement tes soucis de lags.

il y a 34 minutes, totof74 a dit :

Pour que ce post, n'ait pas servi à rien, si j'avais constaté la disparition effective de mes données, quels eut-été la bonne méthode ?

Que ce soit sous Windows ou Linux ou Mac ou .... la méthode reste la même :

1. avec certains systèmes de fichiers, si c'est prévu, on peut sauvegarder les journaux FS (un peu comme le journal des transaction dans une DB)
2. arrêt électrique de l'équipement => on arrache le câble d'alimentation pour limiter les commit/writeback/...
3. dump du disque en mode bloc depuis une autre machine, sans jamais monter le système de fichier
4. puis on tente ce qu'on peut sur le dump (de préférence avec une machine sous le même OS, ici un linux)

[totof74]

Bonjour,

Merci pour cette réponse détaillée, et adaptée à ton auditoire (c'est suffisamment rare sur les forum pour être souligné).

Dans mon cas, les disques ont été ajoutés après l'installation, il n'y a pas trop de fichier tmp / log sur les disques data.

Ceci me semble confirmé par le find -mtime 3 (depuis / ) qui n'affiche que des fichiers se situant dans le volume1.

 

Il y a 8 heures, Fenrir a dit :

Surement un effet secondaire de la petite montée d'adrénaline que tu as du avoir ou plus vraisemblablement tes soucis de lags.

Oui, tu as surement raison, pourtant, j'ai passé 15 bonnes minutes à vérifier et revérifier avant de me faire une raison, qui plus est, la page webman du syno, ne voulait plus s'afficher, ce qui me confortait dans l'idée que j'avais endommagé des fichiers/répertoires.

Par curiosité ce matin, je me suis replacé dans le ./volume2 et j'ai fait un ls, la première fois, il m'a affiché "openvpn.conf", j'ai réessayé plusieurs fois ensuite, et maintenant, il m'affiche bien la liste des fichiers/répertoires... Je pense qu'il y a un mix entre lag et pourquoi pas un petit bug...

Car openvpn.conf n'existe pas sous ./volume2, confirmé par :

/ # find -name "openvpn.conf"
./usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf
./volume1/temp/tmp/openvpn.conf
./volume1/@appstore/VPNCenter/etc/openvpn/openvpn.conf
./volume/openvpn.conf

Le fichier existait déjà dans ./usr et dans @appstore, j'en conclu donc qu'avec mes commandes cp "foireuses", je l'ai copié dans ./volume (dans temp, c'était volontaire).

Bon ça m'apprendra, la prochaine fois, je jetterai un oeil au man avant de me relancer dans une commande linux...

Enfin, pour ce qui est de la récupération des DATA, j'étais au point sur la méthode, c'est plus la question de l'outil que je me posais (je me suis mal exprimé il est vrai).Korben parle de foremost : https://korben.info/recuperer-des-fichiers-effaces-sous-linux-ubuntu.html

Merci encore,

 

 

[totof74]

Je viens de voir que tu avais fait un sujet sur la mise en place du VPN !

Ca tombe bien, car à l'origine, mon problème vient de là !

Sous DSM, quand je clique "Exporter la configuration" (pour openvpn) ça ne fait rien du tout...

Impossible d'exporter la conf, j'ai testé depuis plusieurs machines/navigateurs.

Edit : (Raison pour laquelle je voulais aller chercher le fichier à la main, ce qui est idiot, puisqu'il s'agit du fichier de conf du serveur, pas celui du client..).

Modifié le 6 janvier 2017 par totof74
précisions

[Fenrir]

Il y a 2 heures, totof74 a dit :

Sous DSM, quand je clique "Exporter la configuration" (pour openvpn) ça ne fait rien du tout...

Il faut appliquer la conf et activer le serveur openvpn avant de pouvoir cliquer sur exporter.

Mais sinon tu peux le fabriquer à la main, le fichier n'a rien de spécial.

dev tun
tls-client

remote YOUR_SERVER_IP 1194

# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)

#float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

#redirect-gateway def1

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.

#dhcp-option DNS DNS_IP_ADDRESS

pull

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto udp

script-security 2


comp-lzo

reneg-sec 0

auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
XXXXXX à remplacer par ton certificat en pem
-----END CERTIFICATE-----
</ca>

La dernière section CA est nouvelle, sans doute une des mises à jour récentes

[totof74]

il y a 4 minutes, Fenrir a dit :

Il faut appliquer la conf et activer le serveur openvpn avant de pouvoir cliquer sur exporter.

J'avais bien fait ça... Mais le bouton reste inopérant, quel que soit le système/navigateur.

J'ai tenté effectivement de créer le fichier manuellement, mais sans succès pour l'instant. Du coup, en attendant, j'ai basculé sur IPSEC (grâce à ton tuto), ça fonctionne impec depuis mon android.