Comment by joshstrange | Hacker News Reader

Comment by joshstrange | Hacker News Reader

Forgive me if I'm missing something but this appears to just backup files so it would be fine for source code (should be in version control and safe already) and static assets (like user uploads) but doesn't appear to address things like DB backups which I feel like is the number 1 thing lost if you lose access to your host (followed by user uploads). The problem with DB backups is you can't just backup the data directory (like /var/lib/mysql) unless you've shutdown the DB or you can do a dump (mysqldump) but backing that up hourly is not a good solution IMHO. I guess you could have a replica that you shut down at the top of the hour, backup the data directory, then start back up but all if this is to say this post is not a silver bullet to "Automatically backup a Linux VPS".

This is NOT a knock against the author, I just wanted to point out that "backups" are much more complicated than "copy files elsewhere". For DB's I'd probably consider running a replica on 1 or more other clouds. IDK the logistics of replication over the internet but I know for work we do replication from our datacenter down to our local servers and that's over a relatively slow connection so I assume it's possible to do it from cloud-to-cloud.

Absolutely. Maybe I should have noted that this is more of a guide to make your existing backup procedures more redundant, which implies that you already have local "backups" being made of whatever you want to redundantly store in S3 or B2 or anywhere externally.

In that case, it does become as simple as just copying files elsewhere. (For example, using the Restic steps in my post to backup a folder of hourly database dumps, like you mentioned.) Replicating databases (and other methods made specifically for DBs) is certainly a much, much better route for mission-critical and/or enterprise data.

Covering every permutation of different types of data to backup would have made a long post much longer, but I'll add writing a part two to my to-do list covering rudimentary database backups since that has been brought up here a few times.

Thanks for the feedback! :)

Awesome! I really hope I didn't come across as attacking you/your post, I found it really useful. I just wanted to remind people that the DB wouldn't really be covered by this (except in the case you mentioned where you are dumping the data).

I am definitively looking at this through the lens of where I work where a mysqldump (or equivalent) could take days to complete in full (DB is nearing 2TB in size now). For a number of projects a mysqldump might only take seconds or minutes and would be a perfect candidate for this backup scheme.

Not at all! I'm really glad you mentioned it, since I wrote this in the mindset of small to medium VPSes used for personal projects and I'll make that more clear in the intro. Backups (like everything else, unfortunately) definitely get exponentially more difficult the more successful you become.

The tool I mentioned, xtrabackup, is orders of magnitude faster than mysqldump for both backups an restores. Check it out

FWIW if your DB supports dumping to stdout restic can import that: https://restic.readthedocs.io/en/latest/040_backup.html#read...

Damn, son! Good catch! I have been trying to figure out how to deal with just this problem. Thank you.

For most DBs the simplest path is a db dump, assuming you don't have more data than can be backed up in a reasonable time frame. From there, there's a number of file-systems and other integrations for S3, sftp or similar. You can simply copy out from there. The backup utility in question could be used to target your dump file(s) directory.

Replica's aren't actually a backup, though it's probably a good idea to have them, and in the case of too much data to reasonably backup, as close as you are going to come.

Also, depending on data structures, for example if your data models fit into something like MongoDB or not, it's easy enough to trigger a dump for each record. I've setup systems where primary records are json+gz files in S3 or Azure blobs. In practice this has been as part of the process that will update ElasticSearch (or Mongo) from an RDBMS authority.

It was pretty easy to do <base>/collection/{ID}.json.gz .. from there, worst case, I'd have to create a re-population script from the hard files, and might lose a little less important data, but would always have a hard recovery path. YMMV of course.

I've got 3 side projects that I've been muddling on getting started and some of the things that have happened to the original author frankly scare me. I'm also working on legal structure (LLCs etc) before any real launch. There are so many edge cases to consider, and sometimes it's hard just getting started and accepting that you will make mistakes along the way.

A replica isn't necessarily a backup, if the problem isn't a dead server but a missing WHERE clause in your DELETE query, a replica probably won't save you.

For Postgres you can use something like WAL-E to continuously backup to S3 or other cloud storage providers. The underlying mechanism is explained in the Postgres documentation as "Continuous Archiving and Point-in-Time Recovery (PITR)"(https://www.postgresql.org/docs/11/continuous-archiving.html). Using this method you lose a minimal amount of live data when your main server goes down. And if you need to restore, you can also restore at an arbitrary point of time, so e.g. just before you accidentally deleted everything in a table or something like that.

100% agree, I was talking specifically about protecting against your hosting provider shutting down your account. And a replica coupled with hourly (or whenever) shutdowns, backup data directory, and restart will protect you against a missing WHERE clause on a DELETE.

For MySQL you can use Xtrabackup to take online - non blocking - incremental backups to the filesystem before backing up everything off site with Restic or other.

Reply on news.ycombinator.com