Using version control to manage site backups?

Question

Last week I started making daily backups of my relatively small (~300mb) site. The backups are zipped, so it's less space, but it will quickly add up, especially as my site gets bigger.

I was thinking of unzipping the latest backup, and from now on just using mercurial to add/update files from newer backups.

Are there any drawbacks to this? Is there a better way to do it?

• CamelBlues: Why not just put the site itself in version control? Then backup the repo?

Answer 1

Git is your best choice, since it allows "cheap" commits, branches, etc. every commit is simply a diff of the previous commit, so the size is minimal, for example if you have

index.html
image.png
README.txt
Makefile
main.c

and you only change index.html, then that is all that is stored in the commit, making git extremely space efficient, whats more, it only stores the one or two lines you changed, it could be 500000 line html file (WoAH) making it super fast.

This does mean that the first push to whatever git server that you're using might be long. But everything after that should take no time at all.

And the beautiful thing is, everything can be done locally, you can do as many changes as you want to a local repository, commit as many times as you want, and then push all at once, and since repositories can be local, you can push to just another physical (in the virtual sense :P) on your hard drive, or to a webserver, or through email even!

Answer 2

I use git for this purpose. Assuming unix/linux:

cd /path/to/site
git init
chmod 600 .git
vi .gitignore # add any tmp files you dont want here
git add .
git commit -m "initial commit"

Then, add this to the nightly crontab:

0 3 * * * cd /path/to/project; git add . && git add -u && git commit -m "Daily Commit" 

You could also setup a push to a remote (like github) for true backups.

• mowwwalker: Thanks! Also, what about the sql database? Can I backup that up automatically somehow? And what about the password?

Answer 3

IMO this is the best way, I'm doing it like this as well.
(just commit every change and push the whole thing to a private repository on Bitbucket)

It makes absolutely no sense to always copy the whole 300 MB if only a few files have changed.
Plus, you get a changelog "for free" (which you don't have if you just make a ZIP file every day).

Answer 4

Definitely the way to go here. One additional plus -- you can easily revert changes in many cases if need be. Saved me from more than a few bad updates . . .

Answer 5

Git is a great way to go as others' mentioned. For database (like MySQL), you should be able to create a cron job that runs a script to backup the database and to rotate the the log files.

s, and use daily logging I do something like:

/usr/sbin/logrotate -s status-file logrotate.conf

mysqldump --tables --add_drop_table --user=my-db-username --password='my-password' --host=dbase-server my-database> /the/backup/dir/my-database.sql

My logrotate.conf says to do daily logs, compress, rotate every 14 day. I wildcard it to apply to all *.sql files.