[jaffa214525]

Which is literally the worst scenario. An attacker owns your box and now your backups.

[kornish]

Well, maybe second-worst. The worst would be them getting all your Dropbox files.

[abrookewood]

No, the worst case is actually losing your data ...

[usaphp]

But if he already owns your box what prevents him from accessing your data anyway?

[gcr]

Usually you don't want to give any attackers the ability to destroy all your backups of the server they hacked.

S3's "upload-only" API keys are a solution here: you send the backups into a black hole but the attacker can't delete them.

Looks like Dropbox might not have something like that, giving the attacker read-write access to backups if they can get that API key.

[chatmasta]

How do you avoid that with any backup service?

[toomuchtodo]

Push to an S3 bucket with upload only credentials with versioning turned on.

Your master account (or superuser IAM account if you're paranoid) gives you read/write after 2FA login, but you could share your backup creds with the world and never have your backups pulled out or overwritten.

Use S3 lifecycle rules to expire backup objects after x days; data transfer in is free, the operation requests are pennies per thousand, only the bandwidth is expensive (10 cents/GB) to retrieve the backups when you need to perform a restore (even then, still very cheap).

Also, by storing in S3, you can backup and restore from anywhere.

[TheDong]

Use a pull based one instead of a push based one.

My backup system involves my data storage system reaching out to each machine I want to backup and fetching the data locally.

All I need for that is to put my storage system's public key on the machines, and I'm fine with an attacker getting that.