Considering that virtual hard drives are generally formatted using something like ext3 that abstracts away from the underlying block device, which in and of itself is an abstraction over the top of a physical and network topology.

Is it possible to use something like wipe or shred against a single file or an entire device to mitigate the risk of data being recovered at a later date if that machine was compromised?

  • I don't think this question is something anyone will be able to answer. I would assume each cloud provider has a different methodology for storing/abstracting files and the deletion of them would differ greatly. The process by which your machine is replicated is also abstracted by cloud providers. Who is to say that they appropriately purge the data on the devices that my previous file/drive was running on?
    – Preston Martin
    Jan 23, 2018 at 15:18
  • I think you've got to assume that the cloud provider takes responsibility for protecting and purging of data, by signing a contract to deliver services you are effectively transferring that risk to the cloud service provider. I only mentioned it for context rather than expecting anyone to have found an undocumented /delete?mode=wipe endpoint somewhere in S3. Jan 24, 2018 at 7:39

1 Answer 1


You can't really use those tools with ext3 anyway. Wipe manpage has a large note about it:

No secure deletion program that does filesystem-level calls can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is better implemented in the operating system.

Moreover, the fact the data will be written really in-place is not guaranteed and you may be writing aside the original data.

That said the reason to do this goes back to a point where a data was written on disk on consecutive sectors on the same physical medium, usual storage nowadays use striping technology to spread data on multiple physical medium, each write in the system toward this storage will have an impact on all the stripes this file was part of. Each provider will have its own custom storage backend, but I'm pretty confident the same principles are used.

When you get the picture even higher, you're writing a file on a virtual hard disk which is itself a file on a storage pool, probably streched on multiple lun composed of raid array of physical disks.
There's so many IOs running on all those strates of striping/aggregation that the probability someone could recover a file by magnetic reading of physical disks (what wipe and shred should protect against) is very very very low as the storage used for this file has probably been reused a bunch of time already.

Even on existing ext3/ext4 filesytem, tools like extundelete have a hard time recovering any file if the disk is not unmounted/mounted read only very quickly after the deletion.

  • Thanks, @Tensibai - this is further mitigated by cloud service providers applying encryption of customer data at the Azure Blob/S3 and by applying BitLocker on Windows and DM-Crypt on Linux to encrypt volumes. Jan 24, 2018 at 7:43
  • @RichardSlater I didn't go this way as its another step for securing files, your question sounded more about standard usage and risk of 'undelete' on another instance getting part of the space one of your instance have freed when terminating. Considering AWS, EBD, EFS and S3 are not using the same storage methods from what I can guess so your mileage may vary depending on what you use as instance backend. I kept generic on the actual risk on virtualized environment
    – Tensibai
    Jan 24, 2018 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.