Dalla documentazione AWS
Lo storage a blocchi fisico utilizzato dai volumi EBS eliminati viene sovrascritto con zeri prima di essere assegnato a un altro account.
Da un rappresentante AWS sui loro forum.
Posso confermare che quando un volume di un cliente viene terminato (sia esso EBS o un volume di storage dell'istanza) viene completamente cancellato prima di essere reso disponibile per l'uso da parte di altri clienti.
Se questo è autentico e hai davvero i dati di qualcun altro, devi metterti in contatto con AWS. Affermazioni straordinarie richiedono prove straordinarie.
TLDR; Ho eseguito due serie di test e non sono riuscito a riprodurre i risultati prodotti da @stevelandiss.
Aggiorna - provane uno
L'ho provato io stesso. Ecco cosa ho fatto e i miei risultati.
TLDR; impossibile riprodursi.
0) Ho allocato un'istanza spot m3.medium, con volumi gp2 e io1 (provisioned IOPS), 10 GB ciascuno. Ho usato l'AMI Ubuntu 16.04 standard (ami-b7a114d7). Nota che non potevo montare come /dev/xvdb come suggerito dall'OP, AWS mi ha costretto a usare nomi più lunghi come /dev/xvdba che mi rende leggermente sospettoso.
1) Ho installato photorec/testdisk
apt-get install testdisk
2) Ho usato lsblk per vedere i volumi disponibili
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
-
Ho provato a montare i dischi solo per controllare, ma ovviamente non hanno un file system quindi non è riuscito
mount /dev/xvdba /gp2/mount:tipo fs errato, opzione errata, superblocco errato su /dev/xvdba, codepage mancante o programma di supporto o altro errore
In alcuni casi informazioni utili si trovano in syslog - trydmesg | coda o giù di lì.
3) Ho creato file system su ogni dispositivo
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) Ho montato i dischi
mount /dev/xvdba /gp2/
mount /dev/xvdbb /pio/
5) Ho eseguito il photorec su ogni volume
photorec /dev/xvdba
GP2
IOPS con provisioning IO1
Come puoi vedere non sono stati trovati file. Se @stevelandiss può indicare cosa ha fatto in modo diverso, posso riprovare a riprodurre. Ad esempio, non ha menzionato alcun montaggio e ha utilizzato un nome di dispositivo diverso. Proverò di nuovo senza montare per qualche minuto, ma voglio salvare questo aggiornamento per non perderlo.
Aggiornamento - prova due
Questa volta ho fatto più o meno lo stesso, ma non ho creato un file system o montato il disco. Questo è più vicino a quello che ha fatto @stevelandiss. Questo non ha fatto differenza, nessun file è stato recuperato.
GP2
IOPS con provisioning IO1
dalle pagine man di wipefs:
wipefs non cancella il filesystem stesso né altri dati dal dispositivo
abbiamo bisogno di più informazioni sul volume. Come l'hai creato? Sei sicuro al 100% che nessun altro lo abbia creato oltre a te?
AWS non condivide il modo in cui hanno progettato la tecnologia, quindi suppongo di essere un ragazzo di archiviazione certificato NetApp. I volumi EBS sono livelli di astrazione, costruiti su gruppi RAID. Dubito che sarà solo un singolo disco. Quindi, ogni volta che effettui il provisioning di un volume, otterrai blocchi da diversi dispositivi fisici. Ciò rende molto improbabile che tu possa ottenere file completi.
Forniscici ulteriori informazioni su come hai eseguito il provisioning del volume. Ma immagino che tu stia commettendo un errore ad un certo punto. Altrimenti si tratterebbe di un'enorme violazione della sicurezza su AWS per una funzionalità così basilare.
ecco il test che ho fatto, creo un nuovo volume, una nuova istanza. ha collegato il volume all'istanza e quindi ha eseguito il test photoRec. ho trovato 0 file come previsto.
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.
hai altri utenti IAM nel tuo account? forse hanno allegato quel volume alle loro istanze e l'hanno usato in quel modo.