Backup Central

Dear colleagues,
I'm trying to use rdiff-backup for a backup task and failing
miserably, perhaps
because of an unusual configuration. I'd greatly appreciate your help.

Source: Logical volume on fedora core 4 system
Destination: FAT32 volume mounted locally on the same fedora core 4
system (ie no network)

I _believe_ I have installed rdiff-backup-1.0.1 correctly under python
2.4; in particular, I believe I have installed pylibacl and pxattr
correctly (see below for first 2 lines of directory listing of
/usr/lib)

-rwxr-xr-x 1 root root 66671 Oct 5 13:49 posix1e.so
-rwxr-xr-x 1 root root 13152 Oct 5 13:49 xattr.so

I'm using the following command file to try to do the backup (the
FAT32 file system is mounted at /winhome, and the sub-directory Mirror
is where I intend the mirrored parts of the file system to reside -
I'm not trying to back up the core system files, I think if
resuscitation is ever necessary, it'll be easier to rebuild fc4 from
scratch).

/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /bin /winhome
/Mirror/bin > rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /etc /winhome
/Mirror/etc >> rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /home /winhom
e/Mirror/home >> rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /lib /winhome
/Mirror/lib >> rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /opt /winhome
/Mirror/opt >> rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /root /winhom
e/Mirror/root >> rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /sbin /winhom
e/Mirror/sbin >> rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /selinux /win
home/Mirror/selinux >> rdiff_errs 2>> rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /usr /winhome
/Mirror/usr >> rdiff_errs 2>> rdiff_errs

The resulting error file is attached I'm not sure why rdiff-backup
thinks it is unable to handle access control lists, since posix1e.so
seems to be in the right place? But the more important point is the
unexplained errors subsequently, which seem to reflect problems with
the backup. When I try to re-run rdiff-backup, it complains that, eg:

Starting increment operation /selinux to /winhome/Mirror/selinux
Fatal Error: Bad rdiff-backup-data dir on destination side

The rdiff-backup data directory
/winhome/Mirror/usr/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.

Also, the filesystem sizes are small enough that I don't believe much
has been successfully backed
up (e.g. /usr : 4719348KB -> 6144KB)

I'm at my wits end about this, having spent far more time on it
already than I can afford. But the system contains important data, so
it really _needs_ to be backed up. Any assistance would be
tremendously appreciated

Thanks and Best Wishes
Bob McKay

You can't backup the way you're doing now, by pointing inside dirs inside the
dest-dir to backup to. Rdiff-backup is not rsync. What you want is something
like this:

/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 /
/your/destination/dir/mirror --exlude dir1 --exclude dir2

Things to exlude are "lost+found", "proc", "sys", "mnt" (probably), and so forth.

Why do you backup every system dir BTW if you're only concerned about the
important data you mentioned? That is not located in /bin, I would suspect. I'm
not saying it's wrong to backup system files, because when re-installing fedora
core you can use your backed-up config files, for example, but going with your
statement, it is kind of strange.

Talking about system backups BTW, in my opinion, rdiff-backup is not suitable
for that, should you ever want to restore it. That has two main reasons. The
first being that it checks the mtime of files and dirs to see if they have
changed. This is good for user files, but not for system files. Package managers
may restore old mtimes when doing certain maintainance jobs, to ensure the
manager still knows what files belong to what installed package. The other being
that rdiff-backup matches UIDs and GIDs against the /etc/passwd of the current
system. So, if you're restoring a backup by means of a bootable CD, like
Knoppix, all your (system) users will have UID's that don't match the system you
backed up, but those of the boot CD. There is no way to override this behaviour.

Annoying mailinglist... It should set a reply-address so that replies go to the
list. This one is.

Bob McKay wrote:
I originally tried this, but when I started getting all these errors, I
thought maybe I wasn't excluding stuff I needed to, so decided to do it
instead by an 'include only if reasonably sure it's OK' policy, which was
easier to do by doing separate rdiffs - with excludes, I ended up with a
chain of about 15 excludes, with all the attendant risks of inadvertent
syntax errors, overflowing command line buffers etc.

I don't quite understand how rdiff-backup knows the difference between doing
one backup to one directory, and a number to a number of separate directories
in separate rdiff calls. Does it maintain a persistent global variable of
some sort over separate invocations? Are you certain the errors I was getting
were because of doing the multiple rdiffs? I was getting what appeared
identical errors when I did it with excludes.


I think I misunderstood you. I thought you were pointing into directories inside
an existing rdiff-backup archive, but every dir (bin, home, sbin...) is an
archive of it's own. So you're right, there should be no problem there.

BTW, you said:
But the more important point is the unexplained errors subsequently, which
seem to reflect problems with the backup. When I try to re-run rdiff-backup,
it complains that, eg:

That's not more or less important than your first error. It just says that the
first time went wrong.

And:
I'm not sure why rdiff-backup thinks it is unable to handle access control
lists, since posix1e.so seems to be in the right place?

You are sure you have ACL's? If so, perhaps it has something to do with it being
a LVM. I don't have much experience with ACL's, so I can't help there.

I am kind of confused about the errors you're getting BTW. It's not very clear
which error, if any, is the fatal error. They're most warnings and ingored errors.

When you backup to a non-FAT32 filesystem, what happens then?


I guess I wasn't careful enough in my explanation. I certainly have a number
of bongled config files etc that I do need to back up, and a number of
installed utilities. I could probably get away with just /etc and /usr; but I
included /bin, /sbin etc just to be on the safe side, on the basis that
they're not that big, and don't change that often, so the extra backup cost
was minimal - and if I turn out to be wrong in this, it's easy enough to
remove them later.


Restoring an application by copying the files from /bin etc is not a good idea.
You need to install software through the package manager, or you won't be able
to keep track of what is installed. When just copying files, you end up with a
system you have to reïnstall eventually.



Hmmmm, the former's a rather nasty problem I hadn't thought of. The latter
probably doesn't matter much. It's not my intention to restore the system
from backups - as I said, I would do a clean install; the intention of
including "all but the kitchen sink" in the backup was to be absolutely
certain I wouldn't subsequently discover I had omitted a critical config file
or updated binary. I'm prepared to pay a couple of extra gigs of infrequent
backup over an IDE bus for that peace of mind. If I was more expert in unix
system admin, I'd get my peace of mind from knowledge about what I could
safely exclude; since I don't have that, or the time to get it, better safe
than sorry.

Backing up to another HD poses the same kinds of problem mentioned earlier. When
using "cp", make sure you use "-a" to keep all the properties intact. And, when
restoring, don't restore parts of the backup into an existing system, for the
same maintainability issue as mentioned above.

If you do want to make system backups to removable media in the future, I
recommend Dar (http://dar.linux.free.fr/). It provides everthing you can think
of when doing backups.

Also, you might want to put RAID1 in your computer. Not really hard to do, with
Linux software RAID. Software RAID is better than those RAID controllers on
mainboards BTW. So, unless you have a real hardware RAID card, use software.

On 06/10/2005, at 19:28, Wiebe Cazemier wrote:

Annoying mailinglist... It should set a reply-address so that replies go to the
list. This one is.

Thank you, I'm sorry I missed that on the previous reply.

I'm not sure why rdiff-backup thinks it is unable to handle access
control lists,
since posix1e.so seems to be in the right place?


You are sure you have ACL's? If so, perhaps it has something to do
with it being
a LVM. I don't have much experience with ACL's, so I can't help there.

I am kind of confused about the errors you're getting BTW. It's not very clear
which error, if any, is the fatal error. They're most warnings and
ingored errors.

When you backup to a non-FAT32 filesystem, what happens then?

I'm not certain; I don't have a non-FAT32 filesystem to backup to (I
guess I could use spare space in the same volume, if rdiff-backup
isn't going to be confused by that - in fact, the main disk needs to
be repartitioned, which would solve that problem, but I'm not game to
do that until I have it properly backed up - catch 22.


Restoring an application by copying the files from /bin etc is not a good idea.
You need to install software through the package manager, or you won't be able
to keep track of what is installed. When just copying files, you end up with a
system you have to reïnstall eventually.

Backing up to another HD poses the same kinds of problem mentioned earlier.
When
using "cp", make sure you use "-a" to keep all the properties intact. And, when
restoring, don't restore parts of the backup into an existing system, for the
same maintainability issue as mentioned above.

If you do want to make system backups to removable media in the future, I
recommend Dar (http://dar.linux.free.fr/). It provides everthing you can think
of when doing backups.

Also, you might want to put RAID1 in your computer. Not really hard to do, with
Linux software RAID. Software RAID is better than those RAID controllers on
mainboards BTW. So, unless you have a real hardware RAID card, use software.

Thanks for all the excellent advice - far more than the question I was
originally asking, and all valuable
Best Wishes
Bob McKay

Bob McKay wrote:
I'm not certain; I don't have a non-FAT32 filesystem to backup to (I
guess I could use spare space in the same volume, if rdiff-backup
isn't going to be confused by that - in fact, the main disk needs to
be repartitioned, which would solve that problem, but I'm not game to
do that until I have it properly backed up - catch 22.

rdiff-backup won't mind if you backup to the same partition, it has no reason
to. Just make some dir in /tmp and backup /bin to it or something. Shouldn't
even take much space. If that goes well, then the problem is backing up to FAT32.

BTW, I don't know why I didn't mention this earlier, but FAT32 is a very
unreliable filesystem. I would use ext3 or reiser on your backup disk/partition.
At least use something with journaling.

Thanks for all the excellent advice - far more than the question I was
originally asking, and all valuable

No problem Just making sure you don't mess up your system.

Thanks Wiebe,
Sorry I've been offline on this, I spent the last five days chasing an obsure bug in
my courseware s/w.
Well, we now have a clear definition of the problem: rdiff-backup fails in attempting
to backup to FAT32, but succeeds fine when backing up to the fedora logical volume
(I'm not sure what the fs is - whatever core 4 installs as the default right out of the box).
The command file for backing up to FAT32, and the resulting error file, are listed below
(please ignore any extraneous <cr>s, they're a result of the paste). I don't have much
choice about the file system format for the backup, I need to use the same file system to
share a HD between windows and linux, far as I know the only file system they can both
write to is FAT32. My understanding was that FAT32 was one of the supported file
structures for rdiff-backup?
Best Wishes
Bob

command file:
rm rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 --exclude /dev --exclude /lost+found --exclude /misc --exclude /net --exclude /proc --exclude /srv --exclude /tmp --exclude /var --exclude /boot --exclude /etc --exclude /media --exclude /mnt --exclude /opt --exclude /selinux --exclude /sys --exclude /winhome / /winhome/Mirror >> rdiff_errs 2>> rdiff_errs



error file:
ACLs not supported by filesystem at /
-----------------------------------------------------------------
Detected abilities for source (read only) file system:
Access control lists Off
Extended attributes On
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Warning: hard linking not supported by filesystem at /winhome/Mirror/rdiff-backup-data
Extended attributes not supported by filesystem at /winhome/Mirror/rdiff-backup-data/rdiff-backup.tmp.0
ACLs not supported by filesystem at /winhome/Mirror/rdiff-backup-data/rdiff-backup.tmp.0
-----------------------------------------------------------------
Detected abilities for destination (read/write) file system:
Characters needing quoting '^a-z0-9_ -.'
Ownership changing Off
Hard linking Off
fsync() directories On
Directory inc permissions Off
Access control lists Off
Extended attributes Off
Mac OS X style resource forks Off
Mac OS X Finder information Off
-----------------------------------------------------------------
Starting mirror / to /winhome/Mirror
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line 283, in Main
take_action(rps)
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line 253, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line 306, in Backup
backup.Mirror(rpin, rpout)
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line 38, in Mirror
DestS.patch(dest_rpath, source_diffiter)
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line 218, in patch
ITR(diff.index, diff)
File "/usr/lib/python2.4/site-packages/rdiff_backup/rorpiter.py", line 285, in __call__
last_branch.fast_process(*args)
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line 477, in fast_process
if self.patch_to_temp(rp, diff_rorp, tf):
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line 504, in patch_to_temp
rpath.copy_attribs(diff_rorp, new)
File "/usr/lib/python2.4/site-packages/rdiff_backup/rpath.py", line 162, in copy_attribs
rpout.chmod(rpin.getperms())
File "/usr/lib/python2.4/site-packages/rdiff_backup/rpath.py", line 759, in chmod
self.conn.os.chmod(self.path, permissions)
OSError: [Errno 1] Operation not permitted: '/winhome/Mirror/bin/rdiff-backup.tmp.43'
Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method GzipFile.__del__ of <gzip open file '/winhome/Mirror/rdiff-backup-data/extended_attributes.2005-10-08;08418;05851;05845+09;05800.snapshot.gz', mode 'wb' at 0xb7c6c140 -0x4838a714>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method GzipFile.__del__ of <gzip open file '/winhome/Mirror/rdiff-backup-data/file_statistics.2005-10-08;08418;05851;05845+09;05800.data.gz', mode 'wb' at 0xb7cd1020 -0x4838a7f4>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method GzipFile.__del__ of <gzip open file '/winhome/Mirror/rdiff-backup-data/error_log.2005-10-08;08418;05851;05845+09;05800.data.gz', mode 'wb' at 0xb7f3cf98 -0x4838d1b4>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound method GzipFile.__del__ of <gzip open file '/winhome/Mirror/rdiff-backup-data/mirror_metadata.2005-10-08;08418;05851;05845+09;05800.snapshot.gz', mode 'wb' at 0xb7c6c0f8 -0x4838a7b4>> ignored




On 10/7/05, Wiebe Cazemier <halfgaar < at > gmail.com ([email]halfgaar < at > gmail.com[/email])> wrote: Bob McKay wrote:
I'm not certain; I don't have a non-FAT32 filesystem to backup to (I
guess I could use spare space in the same volume, if rdiff-backup
isn't going to be confused by that - in fact, the main disk needs to
be repartitioned, which would solve that problem, but I'm not game to
do that until I have it properly backed up - catch 22.

rdiff-backup won't mind if you backup to the same partition, it has no reason
to. Just make some dir in /tmp and backup /bin to it or something. Shouldn't
even take much space. If that goes well, then the problem is backing up to FAT32.

BTW, I don't know why I didn't mention this earlier, but FAT32 is a very
unreliable filesystem. I would use ext3 or reiser on your backup disk/partition.
At least use something with journaling.

Thanks for all the excellent advice - far more than the question I was
originally asking, and all valuable

No problem Just making sure you don't mess up your system.


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

Bob McKay wrote:
Thanks Wiebe,
Sorry I've been offline on this, I spent the last five days chasing
an obsure bug in
my courseware s/w.
Well, we now have a clear definition of the problem: rdiff-backup
fails in attempting
to backup to FAT32, but succeeds fine when backing up to the fedora
logical volume
(I'm not sure what the fs is - whatever core 4 installs as the default
right out of the box).

Type "mount" and you'll see. I guess it's ext3, or perhaps reiserfs.

The command file for backing up to FAT32, and the resulting error file,
are listed below
(please ignore any extraneous <cr>s, they're a result of the paste). I
don't have much
choice about the file system format for the backup, I need to use the
same file system to
share a HD between windows and linux, far as I know the only file system
they can both
write to is FAT32. My understanding was that FAT32 was one of the
supported file
structures for rdiff-backup?

FAT32 is indeed supported. My concern is more with the filesystem itself. It's
not very sophosticated and it's unreliable. After all, it's a souped-up version
of a floppy-disk filesystem (FAT12).

BTW, if I'm not mistaken, one of the things rdiff-backup uses for storing and
retrieving information, is the filesystem itself. Modification times are taken
directly out of the filesystem I believe. Now, it also stores this info in meta
files, right? The thing is, which of those does it use when both are available?
If it uses the actual filesystem, your backup archive may get corrupt when
windows strawls through it with a "find file" command. Or, you get .desktop
(etc) files in every dir. Also for this reason, I think it's best to store your
backup somewhere where it is not touched.

Is you data worth 80-100 dollars? If so, buy second harddisk (possible an
external one, USB2). It's a very cheap backup medium. Of course, you could also
buy two extra and build that RAID1 array as well ;)

As for the error you're getting, it seems like a bug, I think you can report it.
There is no error message that I can see, only warnings.

As a follow-up on my previous reply:

I tested what happens if I mess up the mtime of a file in the backup-archive.
When restoring, the data of the metafile is used, so no worries there.

I also tried adding files to the archive and then restoring. The files I
manually added are not restored, so no worries there either.

So it seems you don't have much to worry about, putting your backup on a
partition which Windows can access, but still, FAT32... I wouldn't risk it...
I've lost several gigabytes several times because of FAT32.

Wiebe Cazemier <halfgaar < at > gmail.com>
wrote the following on Wed, 05 Oct 2005 17:17:38 +0200

The other being that rdiff-backup matches UIDs and GIDs against the
/etc/passwd of the current system. So, if you're restoring a backup
by means of a bootable CD, like Knoppix, all your (system) users
will have UID's that don't match the system you backed up, but those
of the boot CD. There is no way to override this behaviour.

That was the old default, the current default is the preserve unames
and gnames (not uids and gids) so restoring to a new system should
work. You can modify this behavior with the --user-mapping-file or
--group-mapping-file switches.


--
Ben Escoto

Bob McKay <urilabob < at > gmail.com>
wrote the following on Mon, 10 Oct 2005 13:23:54 +0900

Well, we now have a clear definition of the problem: rdiff-backup
fails in attempting to backup to FAT32, but succeeds fine when
backing up to the fedora logical volume (I'm not sure what the fs is
- whatever core 4 installs as the default right out of the box).
The command file for backing up to FAT32, and the resulting error
file, are listed below (please ignore any extraneous <cr>s, they're
a result of the paste). I don't have much choice about the file
system format for the backup, I need to use the same file system to
share a HD between windows and linux, far as I know the only file
system they can both write to is FAT32. My understanding was that
FAT32 was one of the supported file structures for rdiff-backup?

Yes, it should work, but Wiebe Cazemier may be right about the
reliability of the file system itself.

Traceback (most recent call last):
...
chmod
self.conn.os.chmod(self.path, permissions)
OSError: [Errno 1] Operation not permitted: '/winhome/Mirror/bin/rdiff-
backup.tmp.43'

Can you run it with high verbosity (maybe 7, or at least 5) so we can
tell what file it's failing on? Then do an ls -al on that file on the
source side and post it.


--
Ben Escoto

Ben Escoto wrote:
That was the old default, the current default is the preserve unames
and gnames (not uids and gids) so restoring to a new system should
work.

I know, I liked the old way better The old way isn't possible anymore, which
I think it should be. Let me explain.

You use rdiff-backup to backup the entire system (putting aside my concerns
about possible mtime presevervations of the package manager, which I described
above). Your HD crashed, and you're going to restore your backup. To do so, you
boot into Knoppix, somehow install rdiff-backup, and restore the backup to a new
HD. Rdiff-backup will match the UID's and GID's of the filesystem to the
/etc/passwd and /etc/group of Knoppix. Let's consider a file which belonged to
"postmaster" on the old sytem, and which had UID 14. If "postmaster" has user ID
15 on Knoppix, the restored file will have UID 15. But, because on the system
that's being restored, UID 15 is "man", the file which should belong to
"postmaster", now belongs to "man" (after booting the restored system of course).

You can modify this behavior with the --user-mapping-file or
--group-mapping-file switches.

The solve my dillema, an option like --preserve-numerical-ids should be
available. Matching against names is perfect when restoring parts of a system,
but not an entire system. It should restore the filesystem as it was, and not
get too smart.

Dear Ben, all,
For the moment, I'm using dar for what I need, so the problem is no
longer urgent for me. I'm also in the process of getting some external
drives, so soon I won't be reliant on a FAT32 system for backup
(thanks Wiebe). On the other hand, I'm happy to assist with debugging.
Below are:
.the command file used (with -v7)
.tail -50 of the errors file
.ls -al and ls -Z of the last file successfully dumped (/bin/more) and
the file causing the failure (/bin/mount)

I guess it feels suspicious that the failure-causing file is
associated with mounting, but is there anything special about
/bin/mount over any other command binary?

Oh by the way, I now know that the source file system is ext3 on top
of a logical volume (I'm learning all the time 8^)

Thanks and Best Wishes
Bob McKay

**********************************************************************************************
command script:
rm rdiff_errs
/usr/bin/rdiff-backup --exclude-special-files --no-hard-links -v4 --exclude /dev
--exclude /lost+found --exclude /misc --exclude /net --exclude /proc --exclude
/srv --exclude /tmp --exclude /var --exclude /boot --exclude /etc --exclude /med
ia --exclude /mnt --exclude /opt --exclude /selinux --exclude /sys --exclude /wi
nhome -v7 / /winhome/Temp >> rdiff_errs 2>> rdiff_errs

**********************************************************************************************
errors file (tail -50):
Processing changed file bin/mknod
Regular copying ('bin', 'mknod') to /winhome/Temp/bin/rdiff-backup.tmp.40
Writing file object to /winhome/Temp/bin/rdiff-backup.tmp.40
Copying attributes from ('bin', 'mknod') to
/winhome/Temp/bin/rdiff-backup.tmp.40
Setting time of /winhome/Temp/bin/rdiff-backup.tmp.40 to 1122305986
Renaming /winhome/Temp/bin/rdiff-backup.tmp.40 to /winhome/Temp/bin/mknod
Processing changed file bin/mktemp
Regular copying ('bin', 'mktemp') to /winhome/Temp/bin/rdiff-backup.tmp.41
Writing file object to /winhome/Temp/bin/rdiff-backup.tmp.41
Copying attributes from ('bin', 'mktemp') to
/winhome/Temp/bin/rdiff-backup.tmp.41
Setting time of /winhome/Temp/bin/rdiff-backup.tmp.41 to 1110054896
Renaming /winhome/Temp/bin/rdiff-backup.tmp.41 to /winhome/Temp/bin/mktemp
Processing changed file bin/more
Regular copying ('bin', 'more') to /winhome/Temp/bin/rdiff-backup.tmp.42
Writing file object to /winhome/Temp/bin/rdiff-backup.tmp.42
Copying attributes from ('bin', 'more') to /winhome/Temp/bin/rdiff-backup.tmp.42
Setting time of /winhome/Temp/bin/rdiff-backup.tmp.42 to 1128089830
Renaming /winhome/Temp/bin/rdiff-backup.tmp.42 to /winhome/Temp/bin/more
Processing changed file bin/mount
Regular copying ('bin', 'mount') to /winhome/Temp/bin/rdiff-backup.tmp.43
Writing file object to /winhome/Temp/bin/rdiff-backup.tmp.43
Copying attributes from ('bin', 'mount') to
/winhome/Temp/bin/rdiff-backup.tmp.43
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line
283, in Main
take_action(rps)
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line
253, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", line
306, in Backup
backup.Mirror(rpin, rpout)
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line
38, in Mirror
DestS.patch(dest_rpath, source_diffiter)
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line
218, in patch
ITR(diff.index, diff)
File "/usr/lib/python2.4/site-packages/rdiff_backup/rorpiter.py",
line 285, in __call__
last_branch.fast_process(*args)
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line
477, in fast_process
if self.patch_to_temp(rp, diff_rorp, tf):
File "/usr/lib/python2.4/site-packages/rdiff_backup/backup.py", line
504, in patch_to_temp
rpath.copy_attribs(diff_rorp, new)
File "/usr/lib/python2.4/site-packages/rdiff_backup/rpath.py", line
162, in copy_attribs
rpout.chmod(rpin.getperms())
File "/usr/lib/python2.4/site-packages/rdiff_backup/rpath.py", line
759, in chmod
self.conn.os.chmod(self.path, permissions)
OSError: [Errno 1] Operation not permitted:
'/winhome/Temp/bin/rdiff-backup.tmp.43'
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method GzipFile.__del__ of <gzip open file
'/winhome/Temp/rdiff-backup-data/extended_attributes.2005-10-15;08418;05858;05834+09;05800.snapshot.gz',
mode 'wb' at 0xb7c100f8 -0x483e6814>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method GzipFile.__del__ of <gzip open file
'/winhome/Temp/rdiff-backup-data/file_statistics.2005-10-15;08418;05858;05834+09;05800.data.gz',
mode 'wb' at 0xb7c100b0 -0x483e68f4>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method GzipFile.__del__ of <gzip open file
'/winhome/Temp/rdiff-backup-data/error_log.2005-10-15;08418;05858;05834+09;05800.data.gz',
mode 'wb' at 0xb7ee0f50 -0x483e92b4>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method GzipFile.__del__ of <gzip open file
'/winhome/Temp/rdiff-backup-data/mirror_metadata.2005-10-15;08418;05858;05834+09;05800.snapshot.gz',
mode 'wb' at 0xb7ee0f98 -0x483e68b4>> ignored

**********************************************************************************************
ls commands:
[root < at > sc bin]# ls -al mount
-rwsr-xr-x 1 root root 81732 Sep 30 23:17 mount
[root < at > sc bin]# ls -Z mount
-rwsr-xr-x root root system_u:object_r:mount_exec_t mount
[root < at > sc bin]# ls -al more
-rwxr-xr-x 1 root root 32172 Sep 30 23:17 more
[root < at > sc bin]# ls -Z more
-rwxr-xr-x root root system_u:object_r:bin_t more
[root < at > sc bin]#




Can you run it with high verbosity (maybe 7, or at least 5) so we can
tell what file it's failing on? Then do an ls -al on that file on the
source side and post it.


--
Ben Escoto

Bob McKay <urilabob < at > gmail.com>
wrote the following on Sat, 15 Oct 2005 19:18:45 +0900
Dear Ben, all,
For the moment, I'm using dar for what I need, so the problem is no
longer urgent for me. I'm also in the process of getting some external
drives, so soon I won't be reliant on a FAT32 system for backup
(thanks Wiebe). On the other hand, I'm happy to assist with debugging.
..
OSError: [Errno 1] Operation not permitted:
'/winhome/Temp/bin/rdiff-backup.tmp.43'
...
[root < at > sc bin]# ls -al mount
-rwsr-xr-x 1 root root 81732 Sep 30 23:17 mount

Hi, thank you very much for your report. The problem is that the
/bin/mount file has its suid bit set (a special permission that makes
it run as root no matter who starts it). Your FAT32 filesystem
doesn't support this special permission and is raising a
misleading-sounding error.

The solution is to have rdiff-backup check to make sure the
destination file system supports special permissions I guess. I
opened a bug at

https://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=14799

about this.

In the meantime, you could avoid running rdiff-backup as root, at
least on the writing side. For instance, instead of

rdiff-backup / /winhome/Temp

you could run:

rdiff-backup / <non-root user> < at > localhost::/winhome/Temp

This should work because rdiff-backup only writes to add the special
permissions if the writing side is running as root.


--
Ben Escoto

Wiebe Cazemier <halfgaar < at > gmail.com>
wrote the following on Sat, 15 Oct 2005 13:30:59 +0200

I know, I liked the old way better The old way isn't possible
anymore, which I think it should be. Let me explain.

You use rdiff-backup to backup the entire system (putting aside my
concerns about possible mtime presevervations of the package
manager, which I described above). Your HD crashed, and you're going
to restore your backup. To do so, you boot into Knoppix, somehow
install rdiff-backup, and restore the backup to a new
HD. Rdiff-backup will match the UID's and GID's of the filesystem to
the /etc/passwd and /etc/group of Knoppix. Let's consider a file
which belonged to "postmaster" on the old sytem, and which had UID
14. If "postmaster" has user ID 15 on Knoppix, the restored file
will have UID 15. But, because on the system that's being restored,
UID 15 is "man", the file which should belong to "postmaster", now
belongs to "man" (after booting the restored system of course).

Ok I get it. I think this feature was requested before but I never
understood the use before. Shouldn't be hard to add---I added a
support request at

https://savannah.nongnu.org/support/index.php?func=detailitem&item_id=104755

and should get to it by the next version.


--
Ben Escoto