Write a little program in your favorite shell or scripting language that
* rsyncs the directories containing the files you want to back up
* mysqldumps/pg_dumps your databases
* zips/gzips everything up into a dated archive file
* deletes the oldest backup (the one with X days ago's date)
Put this program on a VPS at a different provider, on a spare computer in your house, or both. Create a cron job that runs it every night. Run it manually once or twice, then actually restore your backups somewhere to ensure you've made them correctly.
Careful! If someone hacks your server, they now get your Dropbox account.
One alternative is to put these backups into S3 using pre-signed requests rather than Dropbox. An S3 pre-signed request gives permission only to upload files, perhaps only to a certain location in a certain bucket.
It's a bit harder to set up, but the shell script will look almost the same.
You can actually set up app folders in Dropbox so that a particular API key effectively chroots you to that folder. The attacker would only get the backups.
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.
Agreed. It is the backup server which must contain the credentials of the live system and contact it for the backup, and not the other way around. Otherwise an attack on your live system will quickly turn into an attack on your backup system too.
I've used it for many, many years. Setup is a bit of a pain, especially if it's your first time, but it's a totally reliable backup system and gives you something much better than just a pile of zip archives.
All of our servers get BackupPC'd (rsync-over-ssh, pulled) twice a day to an in-house server that's totally unreachable from the internet. I get emails from BackupPC when something goes wrong, which is pretty much never. Backups aren't a thing I have to worry about much anymore.
Or put this program on the same VPS but instead of doing the gzipping and versioning yourself, incorporate Tarsnap[1] into the script. With Tarsnap you can also create a read/write-only key so that if someone hacks your server, a real threat mentioned downthread, they won't be able to delete your backups.
And whatever you do, check that you can actually recover from these backups every once in a while.
My only con against tarsnap is that it can take a long time to do a restore, even for a smallish (30G) backup. Last time I tested at least, I was looking at over three hours. The dev is aware of the issue and may have improved upon it in the meantime.
That is the _only_ reason I have for looking at something else.
I use config management to build the system (Puppet in my case, purely due to experience rather than strong preference) so it's fully reproducible.
I push my data with borg (https://github.com/borgbackup/borg) to rsync.net (http://rsync.net/products/attic.html) for offsite backup.
The simplest way for us it's to use rsync, there is this service decade old (even more) that is just perfect for the offsite backup. http://rsync.net/index.html
We basically create a backup folder (our assets and MySQL Dump, then rsync it to rsync.net). Our source code is already on git, so basically backuped on Github, and all developers computer.
On top of it, rsynch has a very clear and simple documentation to implement it very quickly with any Linux distrib.
Not sure I'd agree there, but it's not inscrutable. I use rsync for almost all file transfers, backups included, so I'm used to it. But there are oddities here and yon.
I hope that you know that your account, like all accounts at rsync.net, is on a ZFS filesystem.
This is important because it means that inside your account, in the .zfs directory, are 7 daily "snapshots" of your entire rsync.net account, free of charge.
Just browse right in and see your entire account as it existed on those days in the past. No configuration or setup necessary. Also, they are immutable/readonly so even if an attacker gains access to your rsync.net account and uses your credentials to delete your data, the snapshots will still be there.
Important question. If it's a Wordpress site, then all you need to back up is the theme and your MySQL db. If it's a static site then just use rsync or sync to a git service.
I use a daily systemd timer on my home machine to remotely back-up the data on my VPS. From there, my home machine backs-up a handful of data from different places to a remote server.
Make sure you check the status of backups, I send journald and syslog stuff to papertrail[0] and have email alerts on failures.
I manually verify the back-ups at least once a year, typically on World Back-up Day [1]
I use AWS S3 for this as the storage prices are so cheap, at $0.03 per GB.
I recommend using a utility called s3cmd, which is a similar to rsync, in that you can backup directories.
I just have this setup with a batch of cron jobs which dump my databases and then sync the directories to s3 weekly.
Also you can configure s3 buckets to delete files older than X days. For non critical projects I tend to set this at 30 days. This way the total storage used by the backups doesn't grow beyond a certain limit and helps you to control the spending.
I host many sites for clients, and use the same approach. Our VPS host offers Plesk (which we use) and it creates a backup every day (basically ZIPs up non-system directories and runs mysqldump / pg_dumps on the databases)... then I wrote a simple bash script which sends the zipped backup to an S3 bucket using s3cmd.
It took a little time to set up, but it is conceptually simple, very inexpensive (especially if you set up S3 to automatically send older files to Glacier, and/or remove old backups every now and then)... and I like that the backups are off-site and stored by a different company than the web hosts.
I use duply (a simpler CLI front-end to duplicity) for doing encrypted incremental backups to S3.
The only annoying thing is that duplicity uses an old version of the boto s3 library that errors out if your signatures tar file is greater than 5gb unless you add `DUPL_PARAMS="$DUPL_PARAMS --s3-use-multiprocessing "` to your duply `conf` file. Took me days to figure that out.
I run a couple of virtualmin web servers which do virtualmin based backups (backs up each website with all its files/email/db's/zones etc into a single file, very much like how cPanel does its account backups), and those are rsynced (cron job) to my home server than runs two mirrored 1tb disks. A simple bash script keeps a few days of backups, plus a weekly backup that I keep two copies of. Overall pretty simple, and it's free since I'm not paying for cloud storage.
We have cheap reliable storage servers at https://mnx.io/pricing -- $15/TB. Couple our storage server with R1soft CDP (r1soft.com), Attic, Rsync, or Innobackupex, etc..
You can also use https://r1softstorage.com/ and receive storage + R1soft license (block based incremental backups) -- or just purchase the $5/month license from them and use storage where you want.
For a static site put it in version control and keep as copy of your full site and deployment code.
For a database driven dynamic site or a site with content uploads you can also use your version control via cron job to upload that content. Have the database journal out the tables you need to backup before syncing to your DVCS host over choice.
If you're looking for a backup service to manage multiple servers with reporting, encryption, dedupelication, etc. I'd love your feedback on our server product: https://www.jungledisk.com/products/server (starts at $5 per month).
The sites I host on DigitalOcean are all very simple Rails sites deployed with Dokku. The source code is in GitHub and the databases I backup hourly to S3 with a very simple cron job.
DigitalOcean has a droplet backup solution priced at 20% of the monthly cost of your droplet. Doesn't get much easier than that, if you can afford it. For a small droplet ($10/month) that's a full backup of everything for a buck a month. https://www.digitalocean.com/community/tutorials/understandi...
Well, most backups are for unseeable events. It's your choice to trust DO's contingency plans but I for one would like to put my eggs in multiple baskets, depends of the value of said eggs of course. I wouldn't set-up off-site backups for a personal website for example.
Unless bug in their system, hack attack or human error deletes all droplets from your account. And yes, I have heard of stories like that from other hosting companies where a human error caused the account to be deleted and data removed.
Is 20% of $10 a $1.00?That said, if you have a small application, I would pay DO to pack it up. They have global servers & imaging/snapshots. Your app would prob be good if you can get away with that kind of hosting.
I do believe you can take images and snapshots and download them, so using the api, a user could prob rig up a script to make it refundant if it was mission critical
I don't think that separating your hosting and backup providers is only necessary for "mission critical" things. If you don't have at least three copies of some data, in at least two distinct physical locations/services then it doesn't exist.
I agree. However, practically speaking I was just pointing out that if cost & time are extremely important and you are bootstrapping a $10 webapp, $2 for 2mins may be the right choice for the OP and people like him, with 0-500 users.
I do agree though. If the answer to the question, "if this data disappeared, would I be more than slightly miffed?" Is not, NO! Then dumping the data offsite makes sense.
The most inportant thing (which I, and many other make the mistake of) is not only backing it up-- but testing restore time.
If you have your entire database on AWS long-term tape storage, it may not even serve utility. If you can't restore a backup in the timeframe nec, then it is essentially the same as having no backup at all
All the databases and other data are backed up to s3. For mysql, we use the python mysql-to-s3 backup scripts.
But the machines themselves are "backed up" by virtue of being able to be rebuilt with saltstack. We verify through nightly builds that we can bring a fresh instance up, with the latest dataset restored from s3, from scratch.
This makes it simple for us to switch providers, and can run our "production" instances locally on virtual machines running the exact same version of CentOS or FreeBSD we use in production.
I just use a simple scheduled AWS lambda to PUT to the redeploy webhook URL.
I use an IAM role with put-only permissions to a certain bucket. Then, if your box is compromised, the backups cannot be deleted or read. S3 can also be setup to automatically remove files older than X days... Also very useful.
On OVH I rsync to another VPS in a different data center. I pick the lowest priced VPS with enough space. I also rsync to a local disk at my home. I would do the same with DO.
OVH has a backup by FTP premium service but the FTP server is accessible only by the VPS it backups. Pretty useless because in my experience if an OVH VPS fails the technical support has never been able to take it back online.
i run a python/shell program to rsync and collect what i want backed up into one folder i then compress it and gpg encrypt it and send it to my backup server
i run a python/shell program to rsync and collect what i want backed up into one folder i then compress it and gpg encrypt it and send it to my backup server
If you use docker to deploy, see cloudron.io. You can install custom apps and it takes care of encrypted backups to s3. And automates lets encrypt as well.
Remember to have automated restore testing that validates restores are successful and the data "freshness" is within a reasonable period of time, such as last updated record in a database.
Lots of people only do a full test of their backup solution when first installing it. Without constant validation of the backup->restore pipeline, it is easy to get into a bad situation and not realize it until it is too late.
Some of our customers have already recommended rsync.net to you - let me remind folks that there is a "HN Readers Discount" - just email us[1] and ask for it.
All automated, with one copy to AWS, one copy to Azure, and an scp local that goes on my home server. Rolling 10, put every 10th backup in cold storage. And I use a different tool for each, just in case.
Whatever strategy you use, make sure you test the process of recreating the server from a backup to make sure you will actually be able to recover. You'll also have an idea how long it will take, and you can create scripts to automate the entire flow so you don't have to figure it all out while you're frantic.
I use tarsnap, as many others in this thread have shared. I also have the Digital Ocean backups option enabled, but I don't necessarily trust it. For the handful of servers I run, the small cost is worth it. Tarsnap is incredibly cheap if most of your data doesn't change from day to day.
93 comments
[ 5.2 ms ] story [ 166 ms ] thread* rsyncs the directories containing the files you want to back up
* mysqldumps/pg_dumps your databases
* zips/gzips everything up into a dated archive file
* deletes the oldest backup (the one with X days ago's date)
Put this program on a VPS at a different provider, on a spare computer in your house, or both. Create a cron job that runs it every night. Run it manually once or twice, then actually restore your backups somewhere to ensure you've made them correctly.
I don't delete and/or gzip my oldest uploads though.
One alternative is to put these backups into S3 using pre-signed requests rather than Dropbox. An S3 pre-signed request gives permission only to upload files, perhaps only to a certain location in a certain bucket.
It's a bit harder to set up, but the shell script will look almost the same.
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.
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.
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.
I've used it for many, many years. Setup is a bit of a pain, especially if it's your first time, but it's a totally reliable backup system and gives you something much better than just a pile of zip archives.
All of our servers get BackupPC'd (rsync-over-ssh, pulled) twice a day to an in-house server that's totally unreachable from the internet. I get emails from BackupPC when something goes wrong, which is pretty much never. Backups aren't a thing I have to worry about much anymore.
And whatever you do, check that you can actually recover from these backups every once in a while.
[1] https://www.tarsnap.com/
That is the _only_ reason I have for looking at something else.
Then on the local Linux box I had a separate script that would doing snapshots of that directory to a complete different place on the filesystem.
Github takes care of code and config.
AWS S3 takes care of uploaded static files.
But Tarsnap takes care of my database backups.
The only thing to be aware of is that restore times can be very slow.
We basically create a backup folder (our assets and MySQL Dump, then rsync it to rsync.net). Our source code is already on git, so basically backuped on Github, and all developers computer.
On top of it, rsynch has a very clear and simple documentation to implement it very quickly with any Linux distrib.
Not sure I'd agree there, but it's not inscrutable. I use rsync for almost all file transfers, backups included, so I'm used to it. But there are oddities here and yon.
I hope that you know that your account, like all accounts at rsync.net, is on a ZFS filesystem.
This is important because it means that inside your account, in the .zfs directory, are 7 daily "snapshots" of your entire rsync.net account, free of charge.
Just browse right in and see your entire account as it existed on those days in the past. No configuration or setup necessary. Also, they are immutable/readonly so even if an attacker gains access to your rsync.net account and uses your credentials to delete your data, the snapshots will still be there.
Stupid simple and stupid cheap. Install, select directories you want backed up, set it and forget it.
All for $7.00 a month.
Make sure you check the status of backups, I send journald and syslog stuff to papertrail[0] and have email alerts on failures.
I manually verify the back-ups at least once a year, typically on World Back-up Day [1]
[0] https://papertrailapp.com/ [1] http://www.worldbackupday.com/en/
Here are the relevant docs: http://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecy...
It took a little time to set up, but it is conceptually simple, very inexpensive (especially if you set up S3 to automatically send older files to Glacier, and/or remove old backups every now and then)... and I like that the backups are off-site and stored by a different company than the web hosts.
The only annoying thing is that duplicity uses an old version of the boto s3 library that errors out if your signatures tar file is greater than 5gb unless you add `DUPL_PARAMS="$DUPL_PARAMS --s3-use-multiprocessing "` to your duply `conf` file. Took me days to figure that out.
You can also use https://r1softstorage.com/ and receive storage + R1soft license (block based incremental backups) -- or just purchase the $5/month license from them and use storage where you want.
For a database driven dynamic site or a site with content uploads you can also use your version control via cron job to upload that content. Have the database journal out the tables you need to backup before syncing to your DVCS host over choice.
If you're looking for a backup service to manage multiple servers with reporting, encryption, dedupelication, etc. I'd love your feedback on our server product: https://www.jungledisk.com/products/server (starts at $5 per month).
I do believe you can take images and snapshots and download them, so using the api, a user could prob rig up a script to make it refundant if it was mission critical
I do agree though. If the answer to the question, "if this data disappeared, would I be more than slightly miffed?" Is not, NO! Then dumping the data offsite makes sense.
The most inportant thing (which I, and many other make the mistake of) is not only backing it up-- but testing restore time.
If you have your entire database on AWS long-term tape storage, it may not even serve utility. If you can't restore a backup in the timeframe nec, then it is essentially the same as having no backup at all
All the databases and other data are backed up to s3. For mysql, we use the python mysql-to-s3 backup scripts.
But the machines themselves are "backed up" by virtue of being able to be rebuilt with saltstack. We verify through nightly builds that we can bring a fresh instance up, with the latest dataset restored from s3, from scratch.
This makes it simple for us to switch providers, and can run our "production" instances locally on virtual machines running the exact same version of CentOS or FreeBSD we use in production.
I just use a simple scheduled AWS lambda to PUT to the redeploy webhook URL.
I use an IAM role with put-only permissions to a certain bucket. Then, if your box is compromised, the backups cannot be deleted or read. S3 can also be setup to automatically remove files older than X days... Also very useful.
OVH has a backup by FTP premium service but the FTP server is accessible only by the VPS it backups. Pretty useless because in my experience if an OVH VPS fails the technical support has never been able to take it back online.
http://backuppc.sourceforge.net/
Lots of people only do a full test of their backup solution when first installing it. Without constant validation of the backup->restore pipeline, it is easy to get into a bad situation and not realize it until it is too late.
[1] info@rsync.net
I use tarsnap, as many others in this thread have shared. I also have the Digital Ocean backups option enabled, but I don't necessarily trust it. For the handful of servers I run, the small cost is worth it. Tarsnap is incredibly cheap if most of your data doesn't change from day to day.