zlacker

The conventional solution to that problem I’ve heard for the last couple decades is to use encryption so the backup doesn’t need to be altered ahead of your normal rotation schedule as long as you can probably drop a customer’s key on demand.

>>acdha+(OP)
The backups are encrypted, but the there is no way for the backup software to know one client's data from the other. Its block based, so all it sees is a volume.

Post hosting providers, or anybody really don't create new volumes for each customer. They would simply have a directory per client. Onces you start needing to know more about the file system then you sort of waste all the benefits block based backups provide.

By block based I mean volume based, were we simply copy the allocated blocks of the file system that changed between each backup.

>>mbruml+qt
I think the parent means encrypt customer data with key specific to that customer. When you erase that customer key their data becomes irreversibly damaged.

>>Boulth+dP1
I get that, but the problem is the way data is stored today it is stored on a single volume. That is many customers are stored on a single volume. When backed up there is normally one key per volume.

I guess the real issue is who will be responsible ensuring backups are stored in a way that different clients are isolated.

As somebody who makes backup software I know the burden will at some point be on my plate.

That being said, if people stored data differently, and did actually have a key per customer then the backup software won't matter, because like the parent and you said, just delete the key. But nothing really works like that today, and it will require a massive amount of software to be rewritten to handle this sort of stuff. So until then either you can't backup your data, or you make the backup provider figure it out.