De la documentación de AWS
El almacenamiento en bloque físico utilizado por los volúmenes de EBS eliminados se sobrescribe con ceros antes de que se asigne a otra cuenta.
De un representante de AWS en sus foros.
Puedo confirmar que cuando cualquier volumen de cliente finaliza (ya sea EBS o un volumen de almacenamiento de instancia) se borra por completo antes de que esté disponible para que lo usen otros clientes.
Si esto es genuino y realmente tiene los datos de otra persona, debe ponerse en contacto con AWS. Las afirmaciones extraordinarias requieren pruebas extraordinarias.
TLDR; Hice dos conjuntos de pruebas y no pude reproducir los resultados que produjo @stevelandiss.
Actualizar:probar uno
Probé esto yo mismo. Esto es lo que hice y mis resultados.
0) Asigné una instancia de spot m3.medium, con volúmenes gp2 e io1 (IOPS aprovisionadas), 10 GB cada uno. Usé la AMI estándar de Ubuntu 16.04 (ami-b7a114d7). Tenga en cuenta que no pude montar como /dev/xvdb como sugirió el OP, AWS me obligó a usar nombres más largos como /dev/xvdba, lo que me hace sospechar un poco.
1) Instalé photorec/testdisk
apt-get install testdisk
2) Usé lsblk para ver los volúmenes disponibles
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
-
Traté de montar los discos solo para verificar, pero, por supuesto, no tienen un sistema de archivos, por lo que falló
mount /dev/xvdba /gp2/mount:tipo de fs incorrecto, opción incorrecta, superbloque incorrecto en /dev/xvdba, página de códigos faltante o programa auxiliar u otro error
En algunos casos, se encuentra información útil en syslog - trydmesg | cola más o menos.
3) Creé sistemas de archivos en cada 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) Monté los discos
mount /dev/xvdba /gp2/
mount /dev/xvdbb /pio/
5) Ejecuté photorec en cada volumen
photorec /dev/xvdba
GP2
IOPS aprovisionadas de IO1
Como puede ver, no se encontraron archivos. Si @stevelandiss puede señalar lo que hizo de manera diferente, puedo intentar reproducirlo nuevamente. Por ejemplo, no mencionó ningún montaje y usó un nombre de dispositivo diferente. Lo intentaré de nuevo sin montar unos minutos, pero quiero guardar esta actualización para no perderla.
Actualización:prueba dos
Esta vez hice casi lo mismo, pero no creé un sistema de archivos ni monté el disco. Esto está más cerca de lo que hizo @stevelandiss. Esto no supuso ninguna diferencia, no se recuperaron archivos.
GP2
IOPS aprovisionadas de IO1
de las páginas man de wipefs:
wipefs no borra el sistema de archivos ni ningún otro dato del dispositivo
Necesitamos más información sobre el volumen. Cómo lo creaste? ¿Estás 100% seguro de que nadie más lo creó excepto tú?
AWS no comparte cómo diseñaron la tecnología, por lo que supongo que soy un tipo de almacenamiento certificado de NetApp. Los volúmenes de EBS son capas de abstracción, creadas en grupos RAID. Dudo que sea un solo disco. Por lo tanto, cada vez que aprovisione un volumen, obtendrá fragmentos de diferentes dispositivos físicos. Eso hace que sea muy poco probable que obtenga archivos completos.
Danos más información sobre cómo aprovisionaste el volumen. Pero supongo que estás cometiendo un error en algún momento. De lo contrario, esto sería una gran violación de seguridad en AWS por una característica tan básica.
aquí está la prueba que hice, creo un nuevo volumen, una nueva instancia. adjuntó el volumen a la instancia y luego ejecutó la prueba photoRec. encontré 0 archivos como se esperaba.
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.
¿Tiene otros usuarios de IAM en su cuenta? tal vez adjuntaron ese volumen a sus instancias y lo usaron de esa manera.