I'm working with Andrew Ferguson to resolve the issue with files > 4GB
on Windows. Neither of us has been able to duplicate the problem, so we
can't really tell if it has been fixed. Does anyone have a file that
triggers the problem so that we can test? We need both the baseline and
modified fi
Helge Milde wrote:
Can you elaborate on this, please? I don't understand what's technically
preventing rdiff-backup from letting me restore a backup from (for
instance) a given date. As far as I understand, rdiff already has all
the data it needs to do a restore, and since it should be a read-on
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 ar
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
Dominic wrote:
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)?
all the locking
Helge Milde wrote:
Can you elaborate on this, please? I don't understand what's technically
preventing rdiff-backup from letting me restore a backup from (for
instance) a given date. As far as I understand, rdiff already has all
the data it needs to do a restore, and since it should be a read-on
I've installed rdiff-backup as follows:
vista x64 : cygwin with rdiff-backup 1.2.1
centos 5.2 on vmware : rdiff-backup 1.2.2
Command: rdiff-backup --force --print-statistics --include-globbing-
filelist /root/backuplist.txt / identityname::/var/_backup
error message:
[root:localhost:~]# rdi
Hi!
I'm trying to restore a backup that has already been written, while a
rdiff-backup is running, and this fails:
machine:/home/user# rdiff-backup -r 1D /some/rdiff-backup/repo/foo .
Fatal Error: It appears that a previous rdiff-backup session with process
id 353 is still running. If two di
Simon Hobson wrote:
Helge Milde wrote:
Can you elaborate on this, please?
OK, say you want to restore file A from some time ago...
Without fully understanding this, would it be possible, if the
repository is inside an LVM logical volume (mine will be, as it so
happens :-)), to create a
Dave Kempe wrote:
all the locking and magic is limited to a repository. hence my
suggestion of having a smaller repository will lead to faster backups
and quicker restores. rdiff-backup retrieves the PID of the
rdiff-backup process if there are two current_mirror markers in the
rdiff-backup da
Dominic wrote:
Without fully understanding this, would it be possible, if the
repository is inside an LVM logical volume (mine will be, as it so
happens :-)), to create a snapshot and then restore from that,
while the original backup proceeds on the original volume? Or would
the snapshot
On Tue, 2008-11-25 at 16:26 +, Simon Hobson wrote:
> The repository would still be locked, as the snapshot would simply
> show your the state of the disk at a set point in time. What you
> could do is to create a snapshot before starting the backup, and then
> destroy it later. I'd guess th
Simon Hobson wrote:
Dominic wrote:
Without fully understanding this, would it be possible, if the
repository is inside an LVM logical volume (mine will be, as it so
happens :-)), to create a snapshot and then restore from that,
while the original backup proceeds on the original volume? Or
Dimi Paun wrote:
On Tue, 2008-11-25 at 16:26 +, Simon Hobson wrote:
The repository would still be locked, as the snapshot would simply
show your the state of the disk at a set point in time. What you
could do is to create a snapshot before starting the backup, and then
destr
Dominic wrote:
Well it may be a plug, but it's justified IMHO for an open-source
product that I had not heard of and that is based on rdiff-backup.
Safekeep is not mentioned at
http://www.nongnu.org/rdiff-backup/related.html. Looks good enough for
me to wish I had seen it earlier. But is it on
Dave Kempe wrote:
thats a good point - we should also add backupninja to that list as well.
Although, they are on the wiki:
http://wiki.rdiff-backup.org/wiki/index.php/ContribScripts
dave
___
rdiff-backup-users mailing list at rdiff-backup-users@no
Dominic wrote:
> Well it may be a plug, but it's justified IMHO for an open-source
> product that I had not heard of and that is based on rdiff-backup.
> Safekeep is not mentioned at
> http://www.nongnu.org/rdiff-backup/related.html. Looks good enough for
> me to wish I had seen it earlier. But i
Although, they are on the wiki:
http://wiki.rdiff-backup.org/wiki/index.php/ContribScripts
True, that's another list I should have studied...
Dominic
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman
18 matches
Mail list logo
