[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is backup a realistic usage of subversion

From: Blair Zajac <blair_at_orcaware.com>
Date: 2006-10-26 01:16:33 CEST

Jan Erik Moström wrote:
> I would appreciate if someone can comment on my ideas.
>
> My problem is that I want to backup my Mac ... and also have my data
> easy accessible on my other machines (primarily Mac but also Linux). I
> currently have a solution that makes disk images of selected folders
> using a cron script, these are then sent to a Linux server where they
> are saved. These files are then backuped using other programs but this
> is outside the scope of the question.
>
> There are two problems with this solution:
>
> + I don't do incremental backups which mean that the disk images become
> quite large and takes a lot of disk space
>
> + It doesn't make my data easy accessible on other computer
>
> I've been thinking of different solution and keep coming back to a
> subversion based solution, that is I put a directory under subversions
> control and put everything I want to backup and share inside that
> folder. Then I make some kind of script that to commits on a regular
> basis so I don't have to remember to do it.
>
> While I've been using subversion for 1-2 years (source code, research
> stuff, etc) I have never done anything like this and I don't know if
> this is a good idea or not, so my questions are:
>
> + Is this a viable solution?
>
> + If I want to add photos, music, etc (large binary files) does
> subversion
> handle this gracefully?
>
> + Is it possible to script subversion to automatically add new
> files/folders
> so I don't have to remember to do it.
>
> + What is the best way to backup a repository like this (I'm going to
> be the only user for this repository and I will be running it on my
> own linux servers)?
>
> My current way of backing up my repositories is to have a small
> post-commit
> script that creates a flag file when a repository is changed. Then I
> have
> a cron script that check if this flag exists and if so it does a dump
> of the whole repositoty, I then keep the last 5 dumps. This works
> well for
> the small repositories I currently have but if I do something like
> what I
> describe above we're talking GBs of data ... so this would probably be
> a bad solution.
>
> I'm pretty sure that the answers of some of these questions are pretty
> basic but I would still appreciate comments if this is a good solution
> for my problem or if I'm trying to use subversion in a way it wasn't
> really designed for.
>
> jem
>
> (and yes, I'm too well aware of the "bundle problem" for certain types
> of documents but I think I can handle those problem)

There is no obliterate for Subversion yet, so after a while, your Subversion
repository would become very large.

I would recommend using rdiff-backup instead. It's what I use to do nightly
backups and it backs my files up incrementally, backs up MacOS X resource forks,
  allows you to delete old backups, etc. It even allows you to store resource
forks on OSes that don't support it, like ext3.

http://www.nongnu.org/rdiff-backup/

You can find rdiff-backup in MacPorts and Fink and many Linux distributions have
them.

The backups rdiff-backup makes look like a normal directory structure, with one
additional rdiff-backup-data, so it's easy to get files out of it on the backup
location.

The one issue is that you shouldn't touch the files in the backup location on
the Linux box.

If you want two working locations that mirror each other and you want to be able
to make changes on the Linux and Mac side and sync them, then take a look at
rsync or unison, but this doesn't provide backups.

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 26 01:17:35 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.