AWS ドキュメントから
<ブロック引用>削除された EBS ボリュームが使用する物理ブロック ストレージは、別のアカウントに割り当てられる前にゼロで上書きされます。
フォーラムの AWS 担当者から。
<ブロック引用>お客様のボリューム (EBS またはインスタンス ストレージ ボリューム) が終了すると、他のお客様が使用できるようになる前に完全に消去されることを確認できます。
これが本物で、実際に他人のデータを持っている場合は、AWS に連絡する必要があります。異常な主張には異常な証拠が必要です。
TLDR; 私は 2 セットのテストを行いましたが、@stevelandiss が生成した結果を再現できませんでした.
更新 - テスト 1
私はこれを自分で試しました。これが私が行ったことと結果です。
TLDR;再現できませんでした。
0) m3.medium スポット インスタンスを割り当て、gp2 および io1 (プロビジョニングされた IOPS) ボリュームをそれぞれ 10 GB 使用しました。標準の Ubuntu 16.04 AMI (ami-b7a114d7) を使用しました。 OP が示唆したように、/dev/xvdb としてマウントできなかったことに注意してください。AWS は、/dev/xvdba のような長い名前を使用することを強制したため、少し疑わしくなります。
1) photorec/testdisk をインストールしました
apt-get install testdisk
2) lsblk を使用して利用可能なボリュームを確認しました
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
-
確認のためにディスクをマウントしようとしましたが、もちろんファイル システムがないため失敗しました
mount /dev/xvdba /gp2/mount:fs タイプが正しくない、オプションが正しくない、/dev/xvdba のスーパーブロックが正しくない、コードページまたはヘルパー プログラムがない、またはその他のエラー
syslog - trydmesg | に有用な情報が見つかる場合があります。尻尾かそこら。
3) 各デバイスにファイルシステムを作りました
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) ディスクをマウントしました
mount /dev/xvdba /gp2/
mount /dev/xvdbb /pio/
5) 各ボリュームでフォトレックを実行しました
photorec /dev/xvdba
GP2
IO1 プロビジョニング済み IOPS
ご覧のとおり、ファイルは見つかりませんでした。 @stevelandiss が彼のやり方の違いを指摘できれば、もう一度再現を試みることができます。たとえば、彼はマウントについて言及しておらず、別のデバイス名を使用していました。数分間マウントせずに再試行しますが、失われないようにこの更新を保存したいと思います.
更新 - テスト 2
今回もほとんど同じことをしましたが、ファイル システムを作成したり、ディスクをマウントしたりしませんでした。これは、@stevelandiss が行ったことに近いものです。これは違いがなく、ファイルは復元されませんでした.
GP2
IO1 プロビジョニング済み IOPS
ワイプのマニュアルページから:
<ブロック引用>Wipefs は、ファイルシステム自体もデバイスからのその他のデータも消去しません
ボリュームに関する詳細情報が必要です。どのように作成しましたか？あなた以外の誰もそれを作成していないことを 100% 確信していますか?
AWS はテクノロジーをどのように設計したかを共有していないので、私は NetApp 認定ストレージ担当者として推測しています。 EBS ボリュームは、RAID グループ上に構築された抽象化レイヤーです。 1枚のディスクだけになるとは思えません。したがって、ボリュームをプロビジョニングするたびに、さまざまな物理デバイスからチャンクを取得します。そのため、完全なファイルを取得する可能性はほとんどありません。
ボリュームのプロビジョニング方法について詳しく教えてください。しかし、あなたはある時点で間違いを犯していると思います。そうしないと、AWS では、このような基本的な機能に関する重大なセキュリティ違反になります。
これが私が行ったテストです。新しいボリューム、新しいインスタンスを作成します。ボリュームをインスタンスにアタッチし、photoRec テストを実行しました。予想どおり 0 個のファイルが見つかりました。
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.
アカウントに他の IAM ユーザーはいますか?そのボリュームをインスタンスにアタッチして、そのように使用したのかもしれません。