Log in

No account? Create an account

Mercurial, Clever or just a weird way to do Backups?

« previous entry | next entry »
Apr. 22nd, 2008 | 10:55 am

All of my sites run a piece of software called Everything. Mine is a fork from the original Everydevel Corp's release. It shares some common traits with Slash but it has a more rapid development cycle that I like.

One of the things it shares with Slash, is that the "site" is the database. AKA everything that makes a site, a site, is the database. This means that a backup of the site can be tossed into an everything container and be up and running in seconds (I use this with virtual machines so that I can move stuff around on a whim).

I hate backups. I don't want to take snapshots with LVM, since I know I just need the content, and typically with dumps I end up with a huge set of these files just sitting around.

  • I cannot search them.
  • I cannot diff them between dates.
  • I cannot partially restore them.
  • They take up a lot of space

    So it dawns on me at dinner last night. What if I just used Mercurial?

    So I add a crontab like so:

    0 3 * * * mysqldump -f --single-transaction -T /var/backup/sitename sitename; (cd /var/backup/sitename; hg commit -m "auto"; hg push)

    I push the backups to a centralized server.

    Instant daily backups, and I can partially restore thanks to the tab format. I can pull diffs that I can directly apply and reinsert into the database.

    Perfect? Nope.

    Mercurial is storing deltas so the space difference does not seem to be to bad (and I am only shipping what changed over the wire). This will not work for my Archive tables, they are just too damn big (4 billion rows and growing). Those tables are just logs and I have a different long term plan for them.

    But the data that makes up the site? Works well.

    Since I use Innodb for sites, I can use the --single-transaction trick to take an online backup. If you are using any other storage engine, the above crontab will lock up your site while the dump is being made.

    This will probably work for most revision systems (if you take one of the nifty ones that can chop history you could even automate the tossing of deltas after a week or so). Mercurial has the strong benefit of being http centric and it is incredibly easy to install as a server (and it has never eaten my data like some other open source systems have).

    I welcome feedback :)
  • Link | Leave a comment |

    Comments {16}

    Lover of Ideas


    from: omnifarious
    date: Apr. 22nd, 2008 11:06 pm (UTC)

    That's an interesting feature. So far, all of the discussion has been about truncating history at some point in the 'past'. Yeah... thinking about it more, being able to collapse portions of the history rather than just truncate is a lot harder and trickier. I think it's possible, but not at all easy.

    I have some ideas on how it might be accomplished even. It's possible, but not easy. It would be easy for the implementer to accidentally corrupt your repository if said implementer wasn't very careful.

    Reply | Parent | Thread

    Brian "Krow" Aker

    Re: Hmmm...

    from: krow
    date: Apr. 23rd, 2008 12:56 am (UTC)

    Easy to keep backups right now :)

    So truncating... how far off is that?

    Reply | Parent | Thread

    Lover of Ideas

    Re: Hmmm...

    from: omnifarious
    date: Apr. 23rd, 2008 06:03 pm (UTC)

    Well, there was someone who expressed interest in doing it as an SoC project. Otherwise I would imagine it would represent 2-3 weeks of concentrated effort on the part of one of the core developers. I'm guessing that if it's not an SoC project it's still many months off.

    Reply | Parent | Thread