[haiku-sysadmin] Re: Migrating dev.haiku-os.org [edition 3 I think]
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-sysadmin@xxxxxxxxxxxxx
- Date: Wed, 14 Oct 2009 23:11:34 +0200
Hi there,
On 2009-10-14 at 22:06:03 [+0200], Niels Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
>
> The configuration for dev.haiku-os.org on vmdev has actually been
> going well and I think it is ready for a migration except for one
> thing.
>
> The issue is the backup procedure. The postgresql documents explicitly
> say it is not a good idea to copy a running data directory [1].
Yep, that's the case for most of the DBMS I know.
> Furthermore, Trac also likes to keep an internal consistency. Now the
> irony is of course that it is very hard to get a synchronized backup
> of both the database and the trac dir, but I have written a backup
> script that first dumps the database and then the trac dir. The
> rationale being that when for example an attachment is made during the
> database backup, it would not be a problem during restore because it
> will only mean that there is a stale file in the trac dir. The other
> way around, so if the trac dir is backed up before the database, there
> would be a database reference to a non-existing file. The first one
> just felt less ... dangerous to me.
Sounds very reasonable.
> Anyway, could this script be (after some adaption) be run before the
> file backups done by baron.haiku-os.org? I guess the script should be
> adapted to create only one backup of the files in the filesystem, as
> the backup process seems to be incremental (and as Oliver explained it
> keeps certain snapshots to roll back).
Yes, I think we could just run that script immediately before syncing the
dev-VM filesystem to baron.
Niels, I think we should just try it out in order to find out if/how the
rsync invocations need to be adjusted to avoid copying the full DB dump and
the trac dump completely, everytime the sync is done.
Having read the pg-docs just now, I find the alternative of doing a single
base backup followed by full WAL-archiving very tempting, as it would only
ever copy the changes of the day onto the backup. In the long run, this
should save a lot of space. However, it seemed a little more tricky to set up
than doing full dumps :-\
cheers,
Oliver
Other related posts:
