41–50 of 94 posts
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.
Earlier quoted context omitted.
It's always good to have your backup off-site. If something happens to DigitalOcean servers, your backups will be gone too.
I imagine DO has some contingency plan to prevent both your server and the backup being down at the same time.
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 ever…
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 imp…
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.
[1] info@rsync.net
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 ever…
Recommended change for additional peace of mind: The backup script does not have deletion privileges. A separate process expires old backups.
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.
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.
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 enabl…
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 enabl…
Is there any reason to not trust DigitalOcean's back up system?