Z dokumentace AWS
Fyzické blokové úložiště používané smazanými svazky EBS je před přidělením jinému účtu přepsáno nulami.
Od zástupce AWS na jejich fórech.
Mohu potvrdit, že když je jakýkoli zákaznický svazek ukončen (ať už je to EBS nebo svazek úložiště instance), je zcela vymazán, než bude zpřístupněn pro použití jinými zákazníky.
Pokud je to pravé a skutečně máte data někoho jiného, musíte se spojit s AWS. Mimořádná tvrzení vyžadují mimořádné důkazy.
TLDR; Provedl jsem dvě sady testů a nebyl jsem schopen reprodukovat výsledky, které vytvořil @stevelandiss.
Aktualizovat – otestovat
Sám jsem to vyzkoušel. Zde je to, co jsem udělal, a mé výsledky.
TLDR; nemohl reprodukovat.
0) Přidělil jsem instanci spotu m3.medium s objemy gp2 a io1 (poskytované IOPS), každý 10 GB. Použil jsem standardní Ubuntu 16.04 AMI (ami-b7a114d7). Všimněte si, že jsem se nemohl připojit jako /dev/xvdb, jak navrhoval OP, AWS mě donutil používat delší názvy jako /dev/xvdba, což ve mně vyvolává mírné podezření.
1) Nainstaloval jsem photorec/testdisk
apt-get install testdisk
2) Použil jsem lsblk, abych se podíval na dostupné svazky
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
-
Zkoušel jsem připojit disky jen pro kontrolu, ale samozřejmě nemají žádný souborový systém, takže to selhalo
mount /dev/xvdba /gp2/mount:špatný typ fs, špatná volba, špatný superblok na /dev/xvdba, chybějící kódová stránka nebo pomocný program nebo jiná chyba
V některých případech jsou užitečné informace nalezeny v syslog - trydmesg | ocas nebo tak.
3) Na každém zařízení jsem vytvořil souborové systémy
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) Namontoval jsem disky
mount /dev/xvdba /gp2/
mount /dev/xvdbb /pio/
5) Spustil jsem photorec na každém svazku
photorec /dev/xvdba
GP2
IOPS zajišťovaný IOPS
Jak vidíte, nebyly nalezeny žádné soubory. Pokud @stevelandiss dokáže poukázat na to, co udělal jinak, mohu to zkusit znovu reprodukovat. Například nezmínil žádnou montáž a použil jiný název zařízení. Zkusím to znovu bez montáže několik minut, ale chci tuto aktualizaci uložit, abych ji neztratil.
Aktualizace – otestujte dvě
Tentokrát jsem udělal totéž, ale nevytvořil jsem souborový systém ani nepřipojil disk. To je blíže tomu, co udělal @stevelandiss. To nic nezměnilo, nebyly obnoveny žádné soubory.
GP2
IOPS zajišťovaný IOPS
z manuálových stránek Wiffs:
Wifs nevymaže samotný souborový systém ani žádná další data ze zařízení
potřebujeme více informací o objemu. Jak jste to vytvořili? Jsi si 100% jistý, že to nevytvořil nikdo jiný než ty?
AWS nesdílí, jak navrhli technologii, takže hádám jako certifikovaný úložiště NetApp. Svazky EBS jsou abstraktní vrstvy postavené na skupinách RAID. Pochybuji, že to bude jen jeden disk. Takže pokaždé, když zřídíte svazek, budete (budete) dostávat bloky z různých fyzických zařízení. Díky tomu je velmi nepravděpodobné, že získáte úplné soubory.
Dejte nám další informace, jak jste svazek zajišťovali. Ale předpokládám, že v určitém okamžiku děláte chybu. Jinak by to bylo obrovské porušení zabezpečení na AWS ohledně takové základní funkce.
zde je test, který jsem provedl, vytvořím nový svazek, novou instanci. připojil svazek k instanci a poté spustil test photoRec. podle očekávání jsem našel 0 souborů.
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.
máte ve svém účtu nějaké další uživatele IAM? možná tento svazek připojili ke svým instancím a použili ho tímto způsobem.