Brian "Krow" Aker's Idle Thoughts - Mercurial, Clever or just a weird way to do Backups?

I think I've mentioned to you before that I use SVN pointing at a NAS drive for backup - it's worked fine for me so far and saved my ass recently when the USB hard drive I was using to migrate my stuff to a new machine died. SVN's never eaten any of my data, near as I can tell, though I don't do any weird things with it.

Anyhow, I found myself wishing I was fluent in Mercurial while I was out in the UK last week - the studio had locked down their Perforce depot (no non-critical checkins for two weeks - ack!), I had to make a ton of changes, and I really needed a bit more flexibility in how I could merge stuff between the locked depot and my local depot.

I've been pondering moving my backup system to Mercurial for similar reasons - it would be nice to commit things locally during the day and then just push to home when I get back to the hotel room.

*laugh*

Thanks, I'd never heard of that.

What are the odds that a method will be done that will allow you to go into a server and collapse older revisions?

I was trying to think of a way of "trimming" so that the repository never had to get super big.

You know... we could just have a "backup mysql" direct to mercurial script :)

Easy to keep backups right now :)

So truncating... how far off is that?

If it works for you, then that's great!

One company I worked for used their version control system for keeping the schema changes (using mysqldump --no-data).

If this technique is used for sensitive data then of course the repository should be secured, as should access to it.

I usually recommend a mysqldump --skip-extended-insert on each table individually as an alternative backup methodology to be able to easily diff backups (table by table). This of course means 2 backups -- one that's consistent, for disaster recovery, and another that isn't, for diff-ability.

Mostly I really like this solution; it shows you have thought about what you really *want* in a backup, and have adjusted your backup plan accordingly. Most folks think a consistent backup is enough, and while it's great for making a new slave, it stinks for incrementals and diffs and whatnot.

I think that in general, using a source control program for backups will work, if what one wants is what the source control program provides. :)

From watching planet mysql for the last few weeks, I've seen about 4 different methods of MySQL backups. None of them have impressed me very much.

Last year during linux world, I was walking around the expo floor, and found a company called r1soft. They back up MySQL with a point-in-time snapshot (no lvm used or needed). For an our of the box solution, we use it, and are very happy with it.

(No, I have no affiliation with r1soft, just like the ease with which backups are made)

Michael

One of the things that really made me happy was that with an existing (non lvm, etc) system, with mixed table types (innodb, myisam), we could just install the r1soft agent, and make a backup of mysql, in real time, with no table locks or downtime, it's incremental, and I can selectively restore certain tables. I've had the (unfortunate) opportunity to test the restores, and they're very painless, even to an alternate server/location.

Michael