Backup Central

hi,

i'm using a synology ds411 nas as backup target. the processor on this
device is very slow, so i don't get a transfer rate of more than 5 mb/s
when accessing it via ssh (cpu-bound). this makes backups for my 500GB
data partition rather painful.

i'd therefore like to interrupt and later resume the initial backup.
however rdiff-backup tells me:
Found interrupted initial backup. Removing...

... and then starts copying the files ... is there any way to resume an
initial backup?

thanks, tim


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Rdiff-backup takes any existing data as a base in a target dir that has to
be initialized, so just remove the rdiff-metadata from the target, while
keeping the data that has already been copied

Cheers
David

-----Ursprüngliche Nachricht-----
Von: rdiff-backup-users-bounces+mail=dkriesel.com < at > nongnu.org
[mailto:rdiff-
backup-users-bounces+mail=dkriesel.com < at > nongnu.org] Im Auftrag von tim
Gesendet: Sonntag, 20. Mai 2012 13:24
An: rdiff-backup-users < at > nongnu.org
Betreff: [rdiff-backup-users] resuming initial backup

hi,

i'm using a synology ds411 nas as backup target. the processor on this
device is very slow, so i don't get a transfer rate of more than 5 mb/s
when accessing it via ssh (cpu-bound). this makes backups for my 500GB
data partition rather painful.

i'd therefore like to interrupt and later resume the initial backup.
however rdiff-backup tells me:
Found interrupted initial backup. Removing...

... and then starts copying the files ... is there any way to resume an
initial backup?

thanks, tim


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

PS.: You might have to --force the backup, not sure, but I know it works ...

-----Ursprüngliche Nachricht-----
Von: rdiff-backup-users-bounces+mail=dkriesel.com < at > nongnu.org
[mailto:rdiff-
backup-users-bounces+mail=dkriesel.com < at > nongnu.org] Im Auftrag von D.
Kriesel
Gesendet: Sonntag, 20. Mai 2012 13:34
An: 'tim'; rdiff-backup-users < at > nongnu.org
Betreff: Re: [rdiff-backup-users] resuming initial backup

Rdiff-backup takes any existing data as a base in a target dir that has to
be initialized, so just remove the rdiff-metadata from the target, while
keeping the data that has already been copied

Cheers
David



_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Not that I know of. Because of the complexity of the underlying archive,
rdiff-backup does not like a failed or interrupted previous backup
attempt at all and tries to remove one if it finds it. Otherwise the
risk would be that you corrupt the archive and lose your data history.
Although it might be possible in theory for rdiff-backup to continue a
previously-interrupted session, the code to do this doesn't exist and
isn't likely to be written.

rsync is good at recovering from broken sessions but then it is not
trying to do anything so complex. But there are some backup tools based
around rsync such as rsnapshot which might work better for you, although
they lack the power of rdiff-backup.

Dominic

On 20/05/2012 12:24, tim wrote:
hi,

i'm using a synology ds411 nas as backup target. the processor on this
device is very slow, so i don't get a transfer rate of more than 5 mb/s
when accessing it via ssh (cpu-bound). this makes backups for my 500GB
data partition rather painful.

i'd therefore like to interrupt and later resume the initial backup.
however rdiff-backup tells me:
Found interrupted initial backup. Removing...

... and then starts copying the files ... is there any way to resume an
initial backup?

thanks, tim


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Hello,

  If you need to store off the box you are rdiffing from then rdiff to a local directory and then rsync that over.


Cheers,


Neil

On 20 May 2012 12:48, Dominic Raferd <dominic < at > timedicer.co.uk ([email]dominic < at > timedicer.co.uk[/email])> wrote:
Not that I know of. Because of the complexity of the underlying archive, rdiff-backup does not like a failed or interrupted previous backup attempt at all and tries to remove one if it finds it. Otherwise the risk would be that you corrupt the archive and lose your data history. Although it might be possible in theory for rdiff-backup to continue a previously-interrupted session, the code to do this doesn't exist and isn't likely to be written.

rsync is good at recovering from broken sessions but then it is not trying to do anything so complex. But there are some backup tools based around rsync such as rsnapshot which might work better for you, although they lack the power of rdiff-backup.

Dominic

On 20/05/2012 12:24, tim wrote:
hi,

i'm using a synology ds411 nas as backup target. the processor on this
device is very slow, so i don't get a transfer rate of more than 5 mb/s
when accessing it via ssh (cpu-bound). this makes backups for my 500GB
data partition rather painful.

i'd therefore like to interrupt and later resume the initial backup.
however rdiff-backup tells me:
Found interrupted initial backup. Removing...

... and then starts copying the files ... is there any way to resume an
initial backup?

thanks, tim


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org ([email]rdiff-backup-users < at > nongnu.org[/email])
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org ([email]rdiff-backup-users < at > nongnu.org[/email])
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki






--

Neil Benn MSc
Ziath Ltd
Phone: +44 (0) 1223 655577
http://www.ziath.com 

Please consider the environment before printing this email.
Follow us on Facebook, Twitter or LinkedIn

IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info < at > ziath.com ([email]info < at > ziath.com[/email]). Thank you.

What exactly needs to be deleted (i.e. the rdiff metadata)? What happens
to the data history (held in the rdiff-backup directory), is it still
all recoverable after you have followed this procedure?

Dominic

On 20/05/2012 12:34, D. Kriesel wrote:
PS.: You might have to --force the backup, not sure, but I know it works ...

-----Ursprüngliche Nachricht-----
Von: rdiff-backup-users-bounces+mail=dkriesel.com < at > nongnu.org
[mailto:rdiff-
backup-users-bounces+mail=dkriesel.com < at > nongnu.org] Im Auftrag von D.
Kriesel
Gesendet: Sonntag, 20. Mai 2012 13:34
An: 'tim'; rdiff-backup-users < at > nongnu.org
Betreff: Re: [rdiff-backup-users] resuming initial backup

Rdiff-backup takes any existing data as a base in a target dir that has to
be initialized, so just remove the rdiff-metadata from the target, while
keeping the data that has already been copied

Cheers
David


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

The whole history will be lost when following this procedure, which renders
it inappropriate for backup repositories whose history actually exists.

However, if I get Tim right, he is talking about an interrupted _initial_
backup run. In this case, giving up the entire history obviously does not do
any harm. Without any metadata (i.e. the rdiff-backup-data subfolder), afaik
a forced rdiff-backup run will take whatever there is in the target folder
as a base and won't retransfer existing parts. So my solution might be the
right thing to do in this special case.

Tim, just to let you know in addition: A more general solution that is
resistant against transmission issues might actually be to
1) rdiff-backup to a local repository, followed by an
2) rsync to the remote box that causes the slow bandwidth.

HTH
David





-----Ursprüngliche Nachricht-----
Von: rdiff-backup-users-bounces+mail=dkriesel.com < at > nongnu.org
[mailto:rdiff-
backup-users-bounces+mail=dkriesel.com < at > nongnu.org] Im Auftrag von
Dominic Raferd
Gesendet: Sonntag, 20. Mai 2012 13:54
An: rdiff-backup-users < at > nongnu.org
Betreff: Re: [rdiff-backup-users] resuming initial backup

What exactly needs to be deleted (i.e. the rdiff metadata)? What happens
to the data history (held in the rdiff-backup directory), is it still
all recoverable after you have followed this procedure?

Dominic

On 20/05/2012 12:34, D. Kriesel wrote:
PS.: You might have to --force the backup, not sure, but I know it works
...

-----Ursprüngliche Nachricht-----
Von: rdiff-backup-users-bounces+mail=dkriesel.com < at > nongnu.org
[mailto:rdiff-
backup-users-bounces+mail=dkriesel.com < at > nongnu.org] Im Auftrag von D.
Kriesel
Gesendet: Sonntag, 20. Mai 2012 13:34
An: 'tim'; rdiff-backup-users < at > nongnu.org
Betreff: Re: [rdiff-backup-users] resuming initial backup

Rdiff-backup takes any existing data as a base in a target dir that has
to
be initialized, so just remove the rdiff-metadata from the target,
while
keeping the data that has already been copied

Cheers
David


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-
backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On 20/05/2012 13:02, D. Kriesel wrote:
The whole history will be lost when following this procedure, which renders
it inappropriate for backup repositories whose history actually exists.

However, if I get Tim right, he is talking about an interrupted _initial_
backup run. In this case, giving up the entire history obviously does not do
any harm. Without any metadata (i.e. the rdiff-backup-data subfolder), afaik
a forced rdiff-backup run will take whatever there is in the target folder
as a base and won't retransfer existing parts. So my solution might be the
right thing to do in this special case.

Ah yes, in that case it might work. Thanks for the explanation

Dominic

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

thanks for your explanations ... i was a bit confused to see a lot of
"Processing changed file" messages of files which have already been
transferred ... could be that checksumming these files is a performance
bottleneck on the NAS device ... so doing the rdiff-backup locally and
uploading via rsync might be an option ...

Yeah, might be that this is the bottleneck. In this case I indeed suggest to
split the backup in two parts: Rdiff-backup locally (quick, robust, no need
for transmissions) and let rsync do the transmission to the target. The
latter might be a lot quicker than a transmission using rdiff-backup, for
rsync usually supposes two files to be identical if filesize and timestamp
match.



_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

hi david,

However, if I get Tim right, he is talking about an interrupted _initial_
backup run. In this case, giving up the entire history obviously does not do
any harm. Without any metadata (i.e. the rdiff-backup-data subfolder), afaik
a forced rdiff-backup run will take whatever there is in the target folder
as a base and won't retransfer existing parts. So my solution might be the
right thing to do in this special case.

thanks for your explanations ... i was a bit confused to see a lot of
"Processing changed file" messages of files which have already been
transferred ... could be that checksumming these files is a performance
bottleneck on the NAS device ... so doing the rdiff-backup locally and
uploading via rsync might be an option ...

thanks, tim

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki