Dave Kempe wrote:
Helge Milde wrote:
If it is intended, are there any workarounds
for this? We need to be able to restore a backup within minutes, and a
backup process can last for 6+ hours (and we do them twice a day).
I believe this is intended behaviour. The backups are mean to be
atomic. Thus its not possible to restore increments inside the time it
takes to backup (ie while the backup is running). However, if you are
not trying to restore an increment, you could just copy the file out of
the repository you wanted (assuming the running backup process has
progressed past that file.
Say you have directories A, B, C, D, and the backup takes ages on C,
but has already done the files in A, then you can just copy them out of
the repository. You only need to involve rdiff-backup for increments.
Other than that, you will probably just have to backup less data in a
job if your time to restore falls inside your backup window.
IE, have more, fewer backup jobs.
It may be intended behaviour but IMHO the --force override ought to be
allowed. Helge's case seems a good example of why one would want to use
this.
Does --force work - or is it even necessary - if accessing a different
repository while an rdiff-backup process is ongoing?
Can one have multiple rdiff-backup sessions running from different
clients simultaneously to one server but to different repositories (I
hope and have assumed so, because this is bound to happen with push
backups, which is the solution I am working towards)?
Dominic
|