"If a bucket's versioning configuration is MFA Delete enabled, the bucket owner must include the x-amz-mfa request header in requests to permanently delete an object version or change the versioning state of the bucket. The header's value is the concatenation of your authentication device's serial number, a space, and the authentication code displayed on it. If you do not include this request header, the request fails."
Yes, so all it takes then if for amazon to either be buggy or to fail for some reason. You can't really outsource responsibility for stuff like backups. They should be under your control and yours alone, and they should not live in the same DC or with the same provider where you store the rest of your data.
And when you've made your backup you take it offline so that no matter what you can get back in business.
Okay then. Where would these backups go? S3 is easy to backup to. Tarsnap is nice. Rsync.net works as well. But these are all online backup options.
If you're advocating offloading to physical media, you need someone who is going to religiously do it (execute code, pull to removable flash drive/SATA dock), and the more up to date you want your backups to be, the more tedious it becomes.
How much are you willing to spend to have AWS Export send you a physical SATA drive nightly?
Why not to a big disk sitting on a computer in your house?
The server doesn't push to it, the home computer pulls from the server (via a cron job or something). That way an attacked can come in from somewhere else. It doesn't have to be perfect, and it shouldn't be your only backup. But having something like that is great for catastrophes like this.
> Why not to a big disk sitting on a computer in your house?
I used to do this to save the $6 and backup locally. Unfortunately, it stopped being practical once the backups hit 3-4 GB since they'd interfere with my internet access in the morning.
Realistically, what I'd do, is have each founder [or just any 2 technical folk really] each setup seperate accounts at two vendors [e.g. Backupsy + Kimsufi] and have the VM pull the backup from the source. I'd keep a week's worth of backups in this way.
No one person could destroy 100% of the backups. A single breach would not destroy 100% of the backups [although it might destroy the production environment depending on permissions].
The cost for such a solution to cover like 1TB of data? $40/month x2.
If you are a funded startup and you aren't able to spend $100/month on securing your backups I'm not sure what to tell you.
> I used to do this to save the $6 and backup locally. Unfortunately, it stopped being practical once the backups hit 3-4 GB since they'd interfere with my internet access in the morning.
3-4 GB of data each day?
I backup data from my personal laptop to digitalocean droplet ($5 month) and then during the night backup droplet (which also stores my mail and other stuff) to the disc connected to raspi in my home. Incremental backup (rdiff-backup) takes literally 5 minutes (3 mins for /home and 2 mins for mail). And amount of data slowly approaches 9GB.
One of the basic premises behind a solid backup strategy is that if disaster hits that it does not hit simultaneously in all places. If that does happen then I think you have different problems to contend with than trying to restore your backups.
I keep a backup of my home data at the office (encrypted volume). Plus another one at a family member's house halfway across the continent (disks are exchanged at family get-togethers)
At its simplest, you should be able to backup to another Amazon S3 setup, that's completely isolated, belonging to a separate account.
Backups should be initiated from a production account access key where "Create" access has been granted, but all the storage and maintenance by another AWS account with it's own access key.
However, I'm not sure that's technically feasible at the moment, without quite a lot of manual scripting
>>You can't really outsource responsibility for stuff like backups. They should be under your control and yours alone
Incorrect.
The best practice is to have multiple backups at different locations, some online, some offline. The offline ones should not all be under your control. For example, companies in certain sectors store copies of their source code in bank vaults, updated once per year. The reason is clear: if something happens to your company (e.g. a plane crashes into your high-rise...), you can recover from an offsite copy of your business data. A company that used to have its headquarters in the Twin Towers recovered from Sept 11 in under 24 hours because they didn't say "all of our backups should be under our control."
Just because something is online does not mean it is not a backup. It can be a backup, it just should not be your only one.
True, although with S3, you can make backups very difficult to remove:
http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMFADelet...
"If a bucket's versioning configuration is MFA Delete enabled, the bucket owner must include the x-amz-mfa request header in requests to permanently delete an object version or change the versioning state of the bucket. The header's value is the concatenation of your authentication device's serial number, a space, and the authentication code displayed on it. If you do not include this request header, the request fails."