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/
Michelle@MICHELLE/
Fatal Error: Bad rdiff-backup-data dir on destination side
The rdiff-backup data directory
/mnt/hda1/rdiffbackup.repositorys/Michelle@MICHELLE/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
tc@10.1.1.150::/mnt/hda1/temp B:/Users/%username%
tc@10.1.1.150::/mnt/hda1/rdiffbackup.repositorys/%username%@%computername%
<mailto:tc@10.1.1.150::/mnt/hda1/rdiffbackup.repositorys/%username%@%computername%>
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 tc@10.1.1.150::/mnt/hda1/temp idea above ?
------------------------------------------------------------------------
Date: Thu, 5 Feb 2015 07:52:02 +0000
From: domi...@timedicer.co.uk
To: rdiff-backup-users@nongnu.org
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/username@computername
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%
tc@10.1.1.150::/mnt/hda1/rdiffbackup.repositorys/%username%@%computername%
<mailto:tc@10.1.1.150::/mnt/hda1/rdiffbackup.repositorys/%username%@%computername%>
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.
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
