Qnap Victime de deadbolt

Je viens d'avoir la confirmation de ICY BOX, que leur fonction clonage par exemple sur le IB-1232CL-U3 c'est bien du bit par bit ( secteur par secteur donc ).
 
Salut à tous.
J'ai (enfin) un peu de temps pour donner suite à mon affaire, alors voilà où j'en suis :

- J'ai installé un dual boot avec Ubuntu 22.04.1 (vous vous rappelez quand j'ai dit que je reviendrais sans doute crier à l'aide ? Bah on y est :D).
- J'ai mis un des disques du RAID1 original de mon NAS dans un boîtier USB SATA (source)
- J'ai acheté deux disques de 4 To pour faire un backup bit par bit des disques qui étaient dans mon NAS, et j'en ai mis un dans un autre boîtier USB - SATA (destination)
- J'aimerais maintenant, avec ddrescue, procéder à une copie des données du disque source vers le disque destination.

Problèmes :
- J'arrive à localiser les partitions qui m'intéressent (source : /dev/sdd3 et destination /dev/sde), mais je n'arrive à en monter aucune : ("impossible à trouver dans /etc/fstab").
- La partition source apparaît comme "Données de base Microsoft". Est-ce cohérent avec du LVM comme ça a été suggéré plus haut dans cette discussion ?

Code:
Disque /dev/sdd : 2,73 TiB, 3000592982016 octets, 5860533168 secteurs
Disk model: ASMT105x        
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 4203DBDC-4CAD-4679-B4A2-94FBCE823E69

Périphérique      Début        Fin   Secteurs Taille Type
/dev/sdd1            40    1060289    1060250 517,7M Données de base Microsoft
/dev/sdd2       1060296    2120579    1060284 517,7M Données de base Microsoft
/dev/sdd3       2120584 5842744109 5840623526   2,7T Données de base Microsoft
/dev/sdd4    5842744112 5843804399    1060288 517,7M Données de base Microsoft
/dev/sdd5    5843804408 5860511999   16707592     8G Données de base Microsoft

Merci encore à ceux qui auront du temps à me consacrer pour vos conseils & indications.

Edit : EVOTk - j'ai recopié la ligne de commande utilisée dans ton test avec ddrescue ; la procédure s'est lancée et m'indique un temps de travail de 1 jour, 4h et 11 minutes... Mon disque destination est dans un vieux boîtier USB 2...
 
Dernière édition:
Salut,
La copie que tu souhaite faire c'est du bit par bit, donc tu n'a pas besoin de t’intéresser aux partitions, mise a part pour être sur que tu es sur le bon disque. ( ici taille 3 To, et un schéma de partitions type QNAP nous confirme qu'on est bien sur le bon disque qu'on souhaite copier /dev/sdd )

5 partitions, c'est le schéma type d'un montage QNAP oui ( la partition de 8G a la fin c'est l'extended swap, je n'ai vu se montage que sur QNAP, pour le "Données de base Microsoft" aucune idée, c'est peut etre mal détecté, je ne serais pas te répondre.

Tu as donc utilisé cela ? :
Code:
ddrescue --force --direct -v /dev/sdX /dev/sdX /tmp/ddrescue1.log

Oui l'USB2 c'est .... Pas rapide :D ?
 
Salut,
La copie que tu souhaite faire c'est du bit par bit, donc tu n'a pas besoin de t’intéresser aux partitions, mise a part pour être sur que tu es sur le bon disque. ( ici taille 3 To, et un schéma de partitions type QNAP nous confirme qu'on est bien sur le bon disque qu'on souhaite copier /dev/sdd )

Oui en effet, je craignais que la commande ddrescue ne fonctionne pas sur des disques non montés, mais finalement ça tourne.

5 partitions, c'est le schéma type d'un montage QNAP oui ( la partition de 8G a la fin c'est l'extended swap, je n'ai vu se montage que sur QNAP, pour le "Données de base Microsoft" aucune idée, c'est peut etre mal détecté, je ne serais pas te répondre.

Ouais, ça ne me dit rien qui vaille, je n'ai pas encore pris le temps de faire des recherches extensives sur le sujet, mais le peu que j'ai trouvé semblait indiquer que la récupération de ce type de partition était compliquée...

Tu as donc utilisé cela ? :
Code:
ddrescue --force --direct -v /dev/sdX /dev/sdX /tmp/ddrescue1.log

Exactement.

Oui l'USB2 c'est .... Pas rapide :D ?

Je prends mon mal en patience. Et j'ai prévenu ma blonde qu'on dormait avec le PC allumé cette nuit.

J'ai aussi une question sur la notion de : "Type d'étiquette de disque : gpt" ; mes autres partitions sont en "dos" ; je ne sais pas si ça a une importance ?

Merci !

Edit : Un souci avec ddrescue, la tâche s'est interrompue avec le message suivant :
Code:
GNU ddrescue 1.23
About to copy 3000 GBytes from '/dev/sdd' to '/dev/sde'
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors       Initial skip size: 58624 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
     ipos:    1404 GB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:    1404 GB, non-scraped:        0 B,  average rate:  17692 kB/s
non-tried:    1595 GB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    1404 GB,   bad areas:        0,        run time: 22h  3m 14s
pct rescued:   46.81%, read errors:        0,  remaining time:     16h 10m
                              time since last successful read:          7s
Copying non-tried blocks... Pass 1 (forwards)
Unaligned read error. Is sector size correct?

Je suis étonné que la taille des secteurs pose problème après 1,4 Tb de copiés, mais je ne suis pas un expert... Est-ce qu'il y a un moyen de reprendre l'opération où elle s'est arrêtée, ou est-ce que je suis bon pour reprendre depuis le début ?
 
Dernière édition:
OK merci pour cette info. J'ai mis le fichier log à l'abri, je l'aurai sous la main pour relancer l'opération en temps voulu.

Du nouveau, je viens de me rendre compte que deux nouvelles partitions apparaissent dans mon explorateur de fichiers, j'ai l'impression qu'elles se trouvent physiquement sur mon disque USB/SATA de destination (je l'entends tourner quand j'accède aux données), et sont donc le fruit du travail incomplet de ddrescue :
- /dev/md9 ; décrite comme "volume de 543 MB", j'accède aux données de cette partition sans problème, j'imagine qu'elle correspond à une des partitions sdd1, sdd2 ou sdd4 de mon disque source. Les données que je veux récupérer ne sont pas là.
- /dev/dm-1 ; décrite comme "3,0 TB chiffrés", qui m'affiche l'invite suivante quand j'essaie de l'ouvrir :

1664725748806.png

Une partition de 3 TB, je me dis que c'est plus probablement là que se trouvent mes données. Seulement voilà :
1 - si j'en crois le log de ddrescue, seuls 1,4 TB ont été copiés en tout ; et c'est environ la moitié du volume de données contenu sur mon disque source.
2 - ... pourquoi c'est "chiffré" ? Je n'ai jamais chiffré (volontairement...) les données de mon NAS.
* Est-ce simplement parce que les données n'ont pas fini de se copier que ça apparaît comme étant chiffré ?
* Est-ce parce que ce disque est issu d'un RAID ? Formaté en LVM ? Pas monté correctement ?
* Y a-t-il un risque que le script de deadbolt se soit réveillé et ait chiffré l'intégralité de la partition à ce niveau quand j'ai remis le disque sous tension ?

3 - pourquoi mon système voit-il le disque de destination (qui apparaît dans "autres emplacements" "sur cet ordinateur") mais pas le disque source, connecté lui aussi en USB ? Le disque destination s'est-il monté tout seul ? Si oui pourquoi ?

Beaucoup de questions... Mais c'est pas fini :

4 - avant de relancer ddrescue, en voilà une autre : je vois que je peux interrompre l'opération en faisant Ctrl+C ; si je fais ça est-ce que je pourrai là aussi la reprendre là où elle se sera arrêtée en me basant sur le fichier log ? Je demande ça parce que je dors quand même mieux avec le PC éteint, et demain y'a école...

5 - Et tant qu'on y est, j'ai fait un nouveau fdisk -l ; et il me détecte entre autres la chose suivante :

Code:
Disque /dev/loop8 : 47,98 MiB, 50315264 octets, 98272 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
La table de partitions GPT de sauvegarde est corrompue, mais la primaire semble fonctionnelle, elle sera donc utilisée.
The backup GPT table is not on the end of the device.

Je ne sais pas localiser physiquement cette partition (je ne sais pas non plus à quoi correspond la mention "loop", mais je constate qu'il y en a quelques autres...). Le fait que la table de partitions GPT soit corrompue vient-il du fait que ddrescue ne s'est pas exécuté jusqu'au bout ?

J'obtiens aussi, pour le disque de destination :

Code:
Disque /dev/sde : 3,64 TiB, 4000787030016 octets, 7814037168 secteurs
Disk model: EFZX-68AWUN0   
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 4203DBDC-4CAD-4679-B4A2-94FBCE823E69

Périphérique      Début        Fin   Secteurs Taille Type
/dev/sde1            40    1060289    1060250 517,7M Données de base Microsoft
/dev/sde2       1060296    2120579    1060284 517,7M Données de base Microsoft
/dev/sde3       2120584 5842744109 5840623526   2,7T Données de base Microsoft
/dev/sde4    5842744112 5843804399    1060288 517,7M Données de base Microsoft
/dev/sde5    5843804408 5860511999   16707592     8G Données de base Microsoft

L'architecture des partitions est identique à celle du disque source ; mais les tailles de secteurs et les tailles d'E/S non : j'étais en (512/4096) pour les tailles de secteur sur la source et (4096/4096) pour les tailles d'E/S. Cela explique peut-être le message d'erreur envoyé par ddrescue : "Unaligned read error. Is sector size correct?". Si oui, comment y remédier ? Y a-t-il des arguments à ajouter à la commande ddrescue pour spécifier une taille de secteur lors de la copie ? Si oui, lesquels ?

Edit : je viens de me rendre compte que l'alim de mon disque source était débranchée... Ma blonde a eu l'excellente idée de passer l'aspirateur sous le bureau. *facepalm*. ddrescue reprend dans la foulée.

Bon, je me rends compte que ce message est passablement bordélique et qu'il doit être compliqué à lire, alors je m'arrête là et je vais laisser la nuit me porter conseil pour les mille autres questions que je me pose. En attendant, merci encore infiniment à ceux qui voudront bien me faire profiter de leur sagesse sur les soucis que j'ai expliqués plus haut.
 
Dernière édition:
2 - ... pourquoi c'est "chiffré" ? Je n'ai jamais chiffré (volontairement...) les données de mon NAS.
Je pense qu'il la considère chiffré car elle est incomplète est non lisible.

* Y a-t-il un risque que le script de deadbolt se soit réveillé et ait chiffré l'intégralité de la partition à ce niveau quand j'ai remis le disque sous tension ?
Non

3 - pourquoi mon système voit-il le disque de destination (qui apparaît dans "autres emplacements" "sur cet ordinateur") mais pas le disque source, connecté lui aussi en USB ? Le disque destination s'est-il monté tout seul ? Si oui pourquoi ?
Alors la ....

4 - avant de relancer ddrescue, en voilà une autre : je vois que je peux interrompre l'opération en faisant Ctrl+C ; si je fais ça est-ce que je pourrai là aussi la reprendre là où elle se sera arrêtée en me basant sur le fichier log ? Je demande ça parce que je dors quand même mieux avec le PC éteint, et demain y'a école...
Idem je serais pas te répondre :ROFLMAO:

Le fait que la table de partitions GPT soit corrompue vient-il du fait que ddrescue ne s'est pas exécuté jusqu'au bout ?
Oui

L'architecture des partitions est identique à celle du disque source
Oui, car il commence par la lors de la copie bit par bit.

mais les tailles de secteurs et les tailles d'E/S non : j'étais en (512/4096) pour les tailles de secteur sur la source et (4096/4096) pour les tailles d'E/S.
Hors de mes compétences :( j'aurai tendance a dire que cela ne devrais pas déranger car tu est plus "petit" sur la destination. Il n'y a donc pas de soucis a copier des blocs de 4K sur 4blocs de 512o ' l'inverse ( coller 1 bloc de 512o sur un bloc de 4K serai plus problématique ).

Edit : je viens de me rendre compte que l'alim de mon disque source était débranchée... Ma blonde a eu l'excellente idée de passer l'aspirateur sous le bureau. *facepalm*. ddrescue reprend dans la foulée.
Ha !
 
3 - pourquoi mon système voit-il le disque de destination (qui apparaît dans "autres emplacements" "sur cet ordinateur") mais pas le disque source, connecté lui aussi en USB ? Le disque destination s'est-il monté tout seul ? Si oui pourquoi ?

il monte tout seul car le systeme a reconue une nouvelle partition quand tu a arreté ddrescue. ( disque vide a ----> ya des nouvelles partitions qui arrive) on peux desactiver le montage automatique des partitions externes je sais plus ou.

4 - avant de relancer ddrescue, en voilà une autre : je vois que je peux interrompre l'opération en faisant Ctrl+C ; si je fais ça est-ce que je pourrai là aussi la reprendre là où elle se sera arrêtée en me basant sur le fichier log ? Je demande ça parce que je dors quand même mieux avec le PC éteint, et demain y'a école...

oui tu pourra reprendre c'est en faisant Ctrl+C qu'on arrête ddrescue

nessai pas de parcourir les partitions non terminer par ddrecue, le système peux avoir tendance a écrire dedans.
 
  • J'aime
Réactions: EVO
Salut à tous et merci pour vos conseils sur ddrescue.

La copie de mon premier disque est terminée (enfin, après quelques péripéties...) et voilà le bilan :

Code:
Current status
     ipos:    2967 GB, non-trimmed:        0 B,  current rate:    2048 B/s
     opos:    2967 GB, non-scraped:        0 B,  average rate:  17891 kB/s
non-tried:        0 B,  bad-sector:     1536 B,    error rate:       0 B/s
  rescued:    3000 GB,   bad areas:        2,        run time:  9h 46m 51s
pct rescued:   99.99%, read errors:        4,  remaining time:          0s
                              time since last successful read:         n/a
Finished

Les 1536 B de "bad sector", les 2 "bad areas" et les 4 "read errors" sont-ils significatifs? Risquent-ils de pénaliser mes tentatives de récupération de données ?
Je vais lancer l'opération pour le second disque, c'est reparti pour 3 jours environ.
 
Salut à tous.

Je double-poste mais j'ai pas trouvé comment éditer mon post d'avant...

Voilà le bilan du ddrescue de mon deuxième disque dur :

Code:
Current status
     ipos:    3000 GB, non-trimmed:        0 B,  current rate:  24797 kB/s
     opos:    3000 GB, non-scraped:        0 B,  average rate:  17817 kB/s
non-tried:        0 B,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    3000 GB,   bad areas:        0,        run time: 12h 56m 55s
pct rescued:  100.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a

La différence entre ces deux disques, c'est que le second n'a pas été débranché subrepticement pendant l'opération de ddrescue à l'occasion d'un passage d'aspirateur intempestif... Et donc j'ai un joli 100 % ici que je n'ai pas sur le premier (cf. le post du dessus).

Question : est-ce que ça craint si je poursuis mon plan tel quel (pour rappel ; le plan est de mettre les deux disques durs de destination de ddrescue dans le NAS et de le démarrer comme ça pour essayer de sauvegarder les données non affectées par deadbolt sans risquer de corrompre les données originales puisque les disques initiaux sont posés sur mon bureau et non alimentés) ; et faut-il que je relance ddrescue sur le premier disque ; ou est-ce que le taux d'erreur assez faible peut être récupéré par le NAS ? Comment ça se passe dans un RAID 1 quand il n'y a pas exactement la même chose sur les deux disques ? Est-ce que mon NAS va forcer une synchronisation qui va remettre mon premier disque au niveau du second ?

Merci pour vos réponses.
 
Salut,
Pour moi tu ne craint rien a essayer ..... sauf a devoir refaire du ddrescue :D

ou est-ce que le taux d'erreur assez faible peut être récupéré par le NAS ?
oui

et 4 secteurs, .. au pire tu aura 1 fichier corrompu, ou non lisible. Vu la situation, je pense que cela serai un moindre mal.

Est-ce que mon NAS va forcer une synchronisation qui va remettre mon premier disque au niveau du second ?
Dépend vraiment de ou ce situe ce secteur problématique, si cela se trouve, il ne gène en rien.
 
Salut, et merci pour ta réponse.

Salut,
Pour moi tu ne craint rien a essayer ..... sauf a devoir refaire du ddrescue :D

J'ai mis les deux nouveaux disques (copies) tels quels dans le NAS, et je viens de le redémarrer. Il m'envoie sur la page d'installation initiale quand j'attaque la page d'accueil via mon PC :

"Bienvenue dans le système d'installation intelligent QTS !
Merci d'avoir choisi QNAP. L'installation intelligente vous guidera tout au long du processus d'installation. Ce processus peut prendre quelques minutes en fonction des disques durs installés."

Et sur le port HDMI ; j'ai une page un peu plus rustique qui me propose à peu près la même chose en anglais, avec 3 notes de bas de page :
Code:
1 - This provides the easiest way to initialize the NAS and lets you instantly use HD Station
2 - For a more detailed configuration, initialize the NAS by going to https://start.qnap.com
3 - All of the data stored on the disks will be deleted upon initialization

Le NAS n'apparaît pas sur mon réseau local.

Je commence à flipper. Je commence à me demander si les manips que j'ai tentées au tout début sous Windows sur les disques initiaux (R-linux, etc.) n'ont pas modifié quelque chose qui empêcherait le NAS d'accéder aux données (puisque de toute évidence il ne retrouve pas sa configuration initiale...). Reste aussi la possibilité que les erreurs de copies sur l'un des disques soient la cause de ce problème.

Ce que je pense faire maintenant, c'est :

1 - Remettre les disques originaux dans le NAS et l'allumer
2 - Soit le système démarre normalement et je me retrouve à la case départ
3 - Soit il me fait la même chose qu'avec les copies, et je serai sérieusement dans la mouise, parce que ça voudra dire que mes disques d'origine ont été modifiés, d'une façon ou d'une autre, et que je ne peux pas accéder aux données via le NAS.

Question :

Est-ce que le NAS peut fonctionner avec deux disques matériellement différents ? Vous me voyez venir, j'envisage aussi de tenter la manip avec un des disques originaux et la copie qui a fonctionné à 100 %.

Merci encore pour le temps que vous prenez à me répondre !
 
Effectivement, ici il ne détecte pas les disques comme portant la signature "QNAP" :(

Est-ce que le NAS peut fonctionner avec deux disques matériellement différents ? Vous me voyez venir, j'envisage aussi de tenter la manip avec un des disques originaux et la copie qui a fonctionné à 100 %.
Tu doit conservé l'autre disque 1 / disque 2 - Tu ne peut par exemple pas metre disque 1 et dans disque 2 une copie de disque 1.
 
OK, bien compris.

Update : mon NAS redémarre normalement avec les disques d'origine ; je retrouve mes comptes, mes données (à première vue dans le même état que quand j'avais tout éteint) *ET* au lieu de la page "deadbolt" qui s'affichait quand j'entrais l'IP du NAS suite à l'attaque ; je retrouve ma page d'accueil "normale". Je me dis que Malware Remover a peut-être fait son boulot malgré tout, avant que n'éteigne le système pour la dernière fois le mois dernier (ou lors du démarrage ce matin), et que deadbolt est peut-être éliminé de ma machine.

QTS me propose d'emblée une mise à jour du firmware (5.0.1.2173 build 20221001) que je suis en train de faire.

Parallèlement, je prépare un de mes deux nouveaux disques de 4 TB (celui qui avait reçu une copie incomplète par ddrescue) pour une partition windows sur laquelle je ferai une copie intégrale des données du NAS.

A moins que deadbolt ne se réveille brusquement et décide de se remettre à chiffrer mes données, je me dis que le pire est peut-être derrière moi.

Et que la semaine que j'ai passée à faire des copies avec ddrescue n'a servi à rien 🙃.

J'espère revenir dans la journée avec un message positif qui mettra un point final à ce sujet. 🤞
 
Si la page deadbolt a disparu, cela signifie que Malwarer Remover l'a placé en quarantaine oui
J'ai effectivement Malware Remover qui me dit que lors du dernier scan, lors du redémarrage de la machine dans la matinée, un programme malveillant a été détecté... Mais je n'en sais pas plus sur les actions entreprises pour neutraliser la menace (la journalisation n'est pas configurée pour malware remover).

Mon NAS est actuellement en train de faire deux choses :
1 - Copier l'ensemble de mes données importantes sur un de mes HDD neufs, connecté en USB/SATA.
2 - Reconstruire le RAID ; opération qui s'est lancée automatiquement dès le redémarrage.

J'ai un avis concernant un de mes deux disques (je vous laisse deviner lequel... Un indice : aspirateur) ; qui m'informe de problèmes matériels sur ce disque :

1665323473270.png

J'envisage de lancer une recherche de blocs défectueux dès que la reconstruction du RAID et/ou la copie de mes données sur DD externe seront terminées, parce que les HDD ont déjà pas mal de boulot là.

Un avis sur cette tactique ?

D'autre part, je vois passer des alertes depuis que j'ai relancé le NAS, des tentatives de connexion avec des login comme "root" ; "administrator", etc.; alors que j'avais (déjà avant l'attaque) suivi une liste de recommandations de QNAP pour protéger l'accès au NAS (désactivé MyQnapCloud, changé le port d'accès, etc.).

Une procédure à suivre pour me mettre à l'abri de tout ça définitivement ?

Merci encore.
 
J'envisage de lancer une recherche de blocs défectueux dès que la reconstruction du RAID et/ou la copie de mes données sur DD externe seront terminées, parce que les HDD ont déjà pas mal de boulot là.
yes, mais cela semble cuit pour ce disque. En général quand on commence a trouver des secteurs problématique, c'est le début de la fin.

D'autre part, je vois passer des alertes depuis que j'ai relancé le NAS, des tentatives de connexion avec des login comme "root" ; "administrator", etc.; alors que j'avais (déjà avant l'attaque) suivi une liste de recommandations de QNAP pour protéger l'accès au NAS (désactivé MyQnapCloud, changé le port d'accès, etc.).
Il ya un point qui a était manqué alors ! Utilise la restriction géographique du pare-feu , ne pas oublier l'ipv6 si c'est actif
 
yes, mais cela semble cuit pour ce disque. En général quand on commence a trouver des secteurs problématique, c'est le début de la fin.

OK... C'est bon à savoir... Après, c'est pas comme si j'avais pas 2 disques de 4 Tb flambants neufs sous le coude...

Il ya un point qui a était manqué alors ! Utilise la restriction géographique du pare-feu , ne pas oublier l'ipv6 si c'est actif

Alors première chose... Je n'avais aucun firewall installé. J'y ai remédié avec QuFirewall, je qu'ai installé et mis en route, configuré pour tout refuser à part les connexions venant de France, à la fois en IPv4 et IPv6.

Ça n'a pas empêché une nouvelle tentative de connexion depuis une IP localisée en Allemagne...