Aus der AWS-Dokumentation
Der physische Blockspeicher, der von gelöschten EBS-Volumes verwendet wird, wird mit Nullen überschrieben, bevor er einem anderen Konto zugewiesen wird.
Von einem AWS-Vertreter in seinen Foren.
Ich kann bestätigen, dass bei Beendigung eines Kunden-Volumes (sei es EBS oder ein Instanzspeicher-Volume) dieses vollständig gelöscht wird, bevor es anderen Kunden zur Verfügung gestellt wird.
Wenn dies echt ist und Sie wirklich die Daten einer anderen Person haben, müssen Sie sich mit AWS in Verbindung setzen. Außergewöhnliche Behauptungen erfordern außergewöhnliche Beweise.
TLDR; Ich habe zwei Testreihen durchgeführt und konnte die Ergebnisse von @stevelandiss nicht reproduzieren.
Aktualisieren - testen
Ich habe das selbst ausprobiert. Hier ist, was ich getan habe und meine Ergebnisse.
TLDR; konnte nicht reproduziert werden.
0) Ich habe eine Spot-Instanz m3.medium mit gp2- und io1-Volumes (bereitgestellte IOPS) mit jeweils 10 GB zugewiesen. Ich habe das Standard-AMI von Ubuntu 16.04 (ami-b7a114d7) verwendet. Beachten Sie, dass ich nicht wie vom OP vorgeschlagen als /dev/xvdb mounten konnte, AWS hat mich gezwungen, längere Namen wie /dev/xvdba zu verwenden, was mich etwas misstrauisch macht.
1) Ich habe photorec/testdisk installiert
apt-get install testdisk
2) Ich habe lsblk verwendet, um mir die verfügbaren Volumes anzusehen
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdba 202:13312 0 10G 0 disk
xvdbb 202:13568 0 10G 0 disk
xvdca 202:19968 0 4G 0 disk
-
Ich habe versucht, die Festplatten nur zur Überprüfung zu mounten, aber natürlich haben sie kein Dateisystem, also ist es fehlgeschlagen
mount /dev/xvdba /gp2/mount:falscher fs-Typ, schlechte Option, fehlerhafter Superblock auf /dev/xvdba, fehlende Codepage oder Hilfsprogramm oder anderer Fehler
In einigen Fällen finden sich nützliche Informationen in syslog -trydmesg | Schwanz oder so.
3) Ich habe Dateisysteme auf jedem Gerät erstellt
mkfs -t ext4 /dev/xvdba
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: e32b2ed1-a0f8-49df-895d-c56b9802a009
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
[email protected]:/home/ubuntu# mkfs -t ext4 /dev/xvdbb
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: 4f1f7c75-bbce-4887-aac7-02e197a36c89
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
4) Ich habe die Festplatten gemountet
mount /dev/xvdba /gp2/
mount /dev/xvdbb /pio/
5) Ich habe photorec auf jedem Volume laufen lassen
photorec /dev/xvdba
GP2
IO1 bereitgestellte IOPS
Wie Sie sehen, wurden keine Dateien gefunden. Wenn @stevelandiss darauf hinweisen kann, was er anders gemacht hat, kann ich erneut versuchen, es zu reproduzieren. Zum Beispiel hat er keine Halterung erwähnt und einen anderen Gerätenamen verwendet. Ich versuche es noch einmal, ohne ein paar Minuten zu mounten, aber ich möchte dieses Update speichern, damit ich es nicht verliere.
Aktualisieren - zwei testen
Diesmal habe ich fast dasselbe getan, aber ich habe kein Dateisystem erstellt oder die Festplatte gemountet. Dies kommt dem, was @stevelandiss getan hat, näher. Dies machte keinen Unterschied, es wurden keine Dateien wiederhergestellt.
GP2
IO1 bereitgestellte IOPS
aus den Manpages von Wiper:
wipefs löscht weder das Dateisystem selbst noch andere Daten vom Gerät
Wir brauchen mehr Informationen über das Volumen. Wie haben Sie es erstellt? Bist du dir zu 100% sicher, dass niemand außer dir es erstellt hat?
AWS teilt nicht mit, wie sie die Technologie entwickelt haben, also schätze ich, dass ich ein NetApp-zertifizierter Speichertyp bin. EBS-Volumes sind Abstraktionsschichten, die auf RAID-Gruppen aufbauen. Ich bezweifle, dass es nur eine einzige Festplatte sein wird. Jedes Mal, wenn Sie ein Volume bereitstellen, erhalten Sie Chunks von verschiedenen physischen Geräten. Das macht es sehr unwahrscheinlich, dass Sie vollständige Dateien erhalten.
Geben Sie uns weitere Informationen darüber, wie Sie das Volume bereitgestellt haben. Aber ich vermute, dass du irgendwann einen Fehler machst. Andernfalls wäre dies eine große Sicherheitsverletzung auf AWS in Bezug auf eine solche grundlegende Funktion.
Hier ist der Test, den ich gemacht habe, ich erstelle ein neues Volume, eine neue Instanz. hängte das Volume an die Instanz an und führte dann den photoRec-Test aus. Ich habe wie erwartet 0 Dateien gefunden.
PhotoRec 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
Disk /dev/xvdf - 1073 MB / 1024 MiB (RO)
Partition Start End Size in sectors
P Unknown 0 0 1 130 138 8 2097152
0 files saved in /home/ec2-user/testdisk-7.0/recup_dir directory.
Recovery completed.
Haben Sie andere IAM-Benutzer in Ihrem Konto? Vielleicht haben sie dieses Volume an ihre Instanzen angehängt und so verwendet.