[rdiff-backup-users] Exception '[Errno 112] Host is down: along with --exclude-other-filesystems

2012-08-22 Thread Gregor Zattler
Dear rdiff-backup community,

today rdiff-backup throw an exception 

Exception '[Errno 112] Host is down: '/mnt/XXX/XXX'' raised of class 
'type 'exceptions.OSError'':

because the host which provided a samba share was not reachable.
This astonishes me because I run rdiff-backup with option
--exclude-other-filesystems and /mnt/XXX/XXX is a mount
point for another file system (which normally is not mounted
while backing up.  Therefore this exception never occurred
before).

Why then is it exceptional that the samba share is not accessible
any more?  Shouldn't it not be touched since it is on another
file system??


Any ideas how to avoid this?

Thanks for your input, Gregor


This is rdiff-backup 1.2.8 on a recent debian testing distribution.

This is how I call rdiff-backup:

DEFAULTOPTIONS='  --terminal-verbosity=4 --verbosity=5  --print-statistics 
--exclude-other-filesystems --no-compression-regexp 
(?i).*\.(gz|z|bz|bz2|xz|lzma|tgz|tbz2|7z|cpgz|zip|lzh|zoo|lharc|rar|rz|arj|rpm|deb|pgp|gpg|jpeg|jpg|gif|png|jp2|mp3|flac|ogg|avi|wmv|wmf|mpeg|mpg|rm|mov)$'

$rdiffbackup  ${DEFAULTOPTIONS}  --backup-mode  --exclude /home  --exclude /etc 
 --exclude /root --exclude /usr/local  / 
${RDIFFBACKUPDESTINATION}/system-cache

This is from the log file 
/mnt/backup/rdiff-backup//system-cache/rdiff-backup-data/backup.log:


Starting increment operation / to /mnt/backup/rdiff-backup//system-cache
Processing changed file .
Incrementing mirror file /mnt/backup/rdiff-backup//system-cache
Exception '[Errno 112] Host is down: '/mnt/XXX/XXX'' raised of class 
'type 'exceptions.OSError'':
  File /usr/lib/python2.7/dist-packages/rdiff_backup/robust.py, line 32, in 
check_common_error
try: return function(*args)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 1149, in 
append
return self.__class__(self.conn, self.base, self.index + (ext,))
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 884, in 
__init__
else: self.setdata()
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 908, in 
setdata
self.data = self.conn.rpath.make_file_dict(self.path)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 287, in 
make_file_dict
return C.make_file_dict(filename)



The output of the command was captured in another log file and is
a bit longer:

Exception '[Errno 112] Host is down: '/mnt/XXX/XXX'' raised of class 
'type 'exceptions.OSError'':
  File /usr/lib/python2.7/dist-packages/rdiff_backup/robust.py, line 32, in 
check_common_error
try: return function(*args)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 1149, in 
append
return self.__class__(self.conn, self.base, self.index + (ext,))
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 884, in 
__init__
else: self.setdata()
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 908, in 
setdata
self.data = self.conn.rpath.make_file_dict(self.path)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py, line 287, in 
make_file_dict
return C.make_file_dict(filename)

Exception '[Errno 112] Host is down: '/mnt/XXX/XXX'' raised of class 
'type 'exceptions.OSError'':
  File /usr/lib/python2.7/dist-packages/rdiff_backup/Main.py, line 304, in 
error_check_Main
try: Main(arglist)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/Main.py, line 324, in 
Main
take_action(rps)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/Main.py, line 280, in 
take_action
elif action == backup: Backup(rps[0], rps[1])
  File /usr/lib/python2.7/dist-packages/rdiff_backup/Main.py, line 343, in 
Backup
backup.Mirror_and_increment(rpin, rpout, incdir)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/backup.py, line 51, in 
Mirror_and_increment
DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath)
  File /usr/lib/python2.7/dist-packages/rdiff_backup/backup.py, line 241, in 
patch_and_increment
for diff in rorpiter.FillInIter(source_diffiter, dest_rpath):
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py, line 177, 
in FillInIter
for rp in rpiter:
  File /usr/lib/python2.7/dist-packages/rdiff_backup/backup.py, line 103, in 
get_diffs
for dest_sig in dest_sigiter:
  File /usr/lib/python2.7/dist-packages/rdiff_backup/backup.py, line 166, in 
get_sigs
for src_rorp, dest_rorp in cls.CCPP:
  File /usr/lib/python2.7/dist-packages/rdiff_backup/backup.py, line 320, in 
next
source_rorp, dest_rorp = self.iter.next()
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py, line 92, in 
Collate2Iters
try: relem1 = riter1.next()
  File /usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py, line 342, 
in next
next_elem = self.iter.next()
  File /usr/lib/python2.7/dist-packages/rdiff_backup/selection.py, line 132, 
in Iterate_fast
try: rpath, val = diryield_stack[-1].next()
  File 

Re: [rdiff-backup-users] Exception '[Errno 112] Host is down: along with --exclude-other-filesystems

2012-08-23 Thread Gregor Zattler
Hi Robert,
* Robert Nichols rnicholsnos...@comcast.net [23. Aug. 2012]:
 On 08/22/2012 02:05 AM, Gregor Zattler wrote:
 There's a bit of a Catch 22 there.  The most straightforward way to find
 that the directory is in a different file system is to issue a stat() call
 and see if st_dev differs from the value for the current file system.  But
 that stat() call will fail if the remote host is down.
 
 Doing the exclude by name should avoid the problem.  Simply excluding
 /mnt/* might suffice, since basically anything under /mnt should be a
 different file system.

Ah.  I didn't do this since I wanted the mount points to be
included in the backup.  Thanks for the explanation, though.  If
the same problem reoccurs I will follow you advise.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

___
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


Re: Doubled dates in old repositories

2020-04-20 Thread Gregor Zattler
Hi Eric,
* "Eric L. Zolf"  [2020-04-20; 07:43]:
> How to detect (under Linux): run `cd MY_BACKUP_REPO; ls -1
> rdiff-backup-data/mirror_metadata.* | sed -e 's/^.*mirror_metadata\.//'
> -e 's/\.[a-z]*.gz$//' | uniq -cd` -> if the output is NOT empty, you
> have the issue.

with this command line I see no output on two repos dating from
2012 for which rdiff-backup -l | wc -l shows 2386 and 2499 lines
respectively.

rdiff-backup is now on version 1.2.8 and both repos are local
ones (meaning there was never a version mismatch of local and
remote rdiff-backup programs involved).

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-




[PATCH] Mention NBD in migration.md

2021-05-16 Thread Gregor Zattler
Mention NBD as another possibility where a filesystem can reside on a
remote host, but is accessed through a local mount point.
---
 docs/migration.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/migration.md b/docs/migration.md
index b761686..990fc82 100644
--- a/docs/migration.md
+++ b/docs/migration.md
@@ -44,7 +44,7 @@ computer. e.g.:
 
 `/source` and `/destination` are paths that reside on the same computer.
 /source or /destination might be remote mounted filesystem like NFS or
-SSHFS.
+SSHFS or reside on a remote NBD.
 
 With this use case to migrate to the latest version, we recommend you to
 simply upgrade your existing installation of rdiff-backup “in-place”.
-- 
2.20.1




Re: what to do if --check-destination-dir ends in traceback?

2021-07-07 Thread Gregor Zattler
Hi Eric,
* "Eric L. Zolf"  [2021-07-06; 07:31]:
> My recommendation would be to throw away the backup repository and start
> a new one, preferably on a different disk drive if you don't know why
> the file system was corrupted in the first place. You don't want to keep
> your backup on hardware you can't trust, do you?
--text follows this line--
thanks.  I'll do so.  I have a second backup on a second
drive for such circumstances.

> If you want to try to fix the repository, it's a purely manual thing and
> there is a high chance to fail; it really depends how much your file
> system got corrupted, and what.
>
> First, you should fix the 2nd issue in order to get a more meaningful
> error message:
> 1. edit /usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py (as root)
> 2. go to line 121
> 3. replace `rpin.path` with `(rpin.index,)` (don't forget the comma)
>
> You can then try again to fix the repository with
> --check-destination-dir -v9.

I did both but it did not help.  Rescuing would be much
error prone guesswork.  Therefore I will copy the file
system of the second backup onto the partition of the first
one, backup to both and see what happens.


> This might allow you to more easily identify which
> rdiff-backup-data/mirror_metadata.[...] file is corrupted, you might
> even be lucky and rdiff-backup finishes the regression with only warnings.
> If it isn't the case, you can try to identify and patch the faulty
> mirror_metadata file by replacing the strange looking fields with
> meaningful values (or remove them altogether); the mirror_metadata will
> need to be uncompressed and re-compressed. The issue is that if it's a
> not so obvious field (e.g. the size), it'll become difficult to find the
> correct value (I would look at the mirror and assume the file hasn't
> changed since then, but it might not help).
>
> As you see, it's not easy, and it might only be the first corruption in
> a row of other corruptions, some might not get detected immediately.
> If you succeed to rollback, you should also run a --verify. But IMHO
> you'll never be 100% sure that your backup repo is fully correct.
>
> Hence my strong personal recommendation is to forget about it and start
> a new repo, you can still keep the old one if you think you might need a
> file from it at some point in time.
>
> Nothing is worse than a backup you aren't sure you can trust.

Yes.  Thanks for your attention and help, Gregor




what to do if --check-destination-dir ends in traceback?

2021-07-05 Thread Gregor Zattler
Dear rdiff-backup users and developers,

lately I had to do a fsck.ext4 -y on the filesystem which
hosts my rdiff-backup.  Then I had tracebacks when I
attempted the next backup.  What to do in such a case?

Is there any hope to revive this rdiff-backup?

This is rdiff-backup 1.2.8 on Debian 10.10 (buster):



$ sudo rdiff-backup --check-destination-dir 
/mnt/usb-backup/rdiff-backup/durable/
Unknown field in line '9e r1ons000'
Unknown field in line '9e 10a595828229'
Exception 'RORPath instance has no attribute 'path'' raised of class '':
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in 
error_check_Main
try: Main(arglist)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in 
Main
take_action(rps)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 282, in 
take_action
elif action == "check-destination-dir": CheckDest(rps[0])
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 872, in 
CheckDest
dest_rp.conn.regress.Regress(dest_rp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 71, in 
Regress
for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py", line 281, 
in __call__
last_branch.fast_process(*args)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 274, in 
fast_process
else: rpath.copy_with_attribs(rf.metadata_rorp, rf.mirror_rp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 243, in 
copy_with_attribs
copy(rpin, rpout, compress)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 121, in 
copy
else: raise RPathException("File %s has unknown type" % rpin.path)

Traceback (most recent call last):
  File "/usr/bin/rdiff-backup", line 30, in 
rdiff_backup.Main.error_check_Main(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 304, in 
error_check_Main
try: Main(arglist)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 324, in 
Main
take_action(rps)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 282, in 
take_action
elif action == "check-destination-dir": CheckDest(rps[0])
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/Main.py", line 872, in 
CheckDest
dest_rp.conn.regress.Regress(dest_rp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 71, in 
Regress
for rf in iterate_meta_rfs(mirror_rp, inc_rpath): ITR(rf.index, rf)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rorpiter.py", line 281, 
in __call__
last_branch.fast_process(*args)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/regress.py", line 274, in 
fast_process
else: rpath.copy_with_attribs(rf.metadata_rorp, rf.mirror_rp)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 243, in 
copy_with_attribs
copy(rpin, rpout, compress)
  File "/usr/lib/python2.7/dist-packages/rdiff_backup/rpath.py", line 121, in 
copy
else: raise RPathException("File %s has unknown type" % rpin.path)
AttributeError: RORPath instance has no attribute 'path'


Thanks for your attention, Gregor