Re: [rdiff-backup-users] backup keeps failing

[Dominic Raferd]

I don't think temporary space is likely to be an issue on the destination machine when doing a backup run. But if you want to rule out the out-of-temp issue at the destination when running rdiff-backup remotely, you need to use the --remote-tempdir switch, not --tempdir.

Removing the rdiff-backup-data subdirectory from your repository - as you did - will destroy the repository I think; IMO the error message that suggests it is confusing at best. Time to start over, I agree.

How much swap space does your microcore machine have? And how much processing power?

Dominic

On 06/02/2015 02:56, Stephen Butler wrote:

Just tried deleting the rdiff-backup-data folder 

and ran the backup again, got the following error.

Run rdiff-backup...

Connection to 10.1.1.150 closed by remote host.

Fatal Error: lost connection to the remote system.

The next thing to try is to completly delete the users backup on the server.

And start again.

I'm in a bit of a loop here.

Remus

Hello Dominic,

I tried running the command, and got the following error. Which is logical based on your expectation of corrupted backup.

$  rdiff-backup --check-destination-dir --tempdir /mnt/hda1/temp/ address@hiddenELLE/ 

Fatal Error: Bad rdiff-backup-data dir on destination side

The rdiff-backup data directory

/mnt/hda1/rdiffbackup.repositorys/address@hidden/rdiff-backup-data

exists, but we cannot find a valid current_mirror marker.  You can

avoid this message by removing the rdiff-backup-data directory;

however any data in it will be lost.

Probably this error was caused because the first rdiff-backup session

into a new directory failed.  If this is the case it is safe to delete

the rdiff-backup-data directory because there is no important

information in it.

I have actually tried deleting the backup and starting again a few times now.

Perhaps my poor server does not have the grunt for rdiff-backup ?

$ cat /proc/meminfo

MemTotal:        1026412 kB

MemFree:           14360 kB

The system is running a P4 2.8 Ghz cpu.

Does using the --tempdir command during backup help ?

For example.

rdiff-backup --force -v3 --print-statistics --tempdir address@hidden::/mnt/hda1/temp B:/Users/%username% address@hidden::/mnt/hda1/rdiffbackup.repositorys/address@hidden

Is there a problem with running multiple rdiff-backup jobs from win workstations to the server ? Perhaps that would be mitigated if I can use the --tempdir address@hidden::/mnt/hda1/temp idea above ?

---

Date: Thu, 5 Feb 2015 07:52:02 +0000
From: address@hidden
To: address@hidden
Subject: Re: [rdiff-backup-users] backup keeps failing

I doubt is to do with SSH. My guess is that your (C) backup repository was already somehow corrupted on the destination. So when you tried to run another session to it, rdiff-backup automatically started a regression to get back to a safe starting point for the backup. In itself this can take a very long time, and also regressions of larger archives can require a *lot* of temporary space; if this runs out then the backup might hang. I suggest running something like this on the server:

rdiff-backup --check-destination-dir --tempdir /somewhere/with/lots/of/space /mnt/hda1/rdiffbackup.repositorys/address@hidden

On 05/02/2015 04:54, Stephen Butler wrote:

Hi all,

I have 3 windows 7 computers scheduled to perform an rdiff-backup over ssh to a microcore linux server each day at 6pm.

Backups are triggered on all 3 computers at 6pm by windows task scheduler each day.

I'm using volume shadowing to create a snapshot of my files, which is needed for open outlook pst files.

Here's an example.

rdiff-backup --force -v3 --print-statistics B:/Users/%username% address@hidden::/mnt/hda1/rdiffbackup.repositorys/address@hidden

Win 7 PC (A) backup is under 1 gb and works each day. Takes about a minute.

Win 7 PC (B) backup is under 2 gb and works each day. Takes about two minutes.

Win 7 PC (C) backup is 45 gb and takes more than 12 hours to complete. I ran the backup last night at 6pm and it was still running this morning at 11am. I cancelled the backup, and ended up with a corrupted backup.

Is this to do with SSH slowing down the process ?

I hope to find a solution to this problem, as another system I'd like to use rdiff-backup on has over 250gb of data to check.

Any suggestions are greatly appreciated.

Thanks,

Remus.