Package: rsync
Version: 3.0.7-1~bpo50+1
Severity: normal
Hi,
I am using rsync to make local copies of my root filesystem to a backup
partition. The source "/" filesystem is read-only, and the system is
running having been booted into "emergency" mode, like this,
# cat /proc/cmdline
root=/dev/sda6 ro -b SUSHELL=/root/-sh
and rsync is run (using make) like this,
env time sh -c "set -e ; set -u ; cd / ; rsync -rlptgoDH -x --del --inplace
./ /dev/sdb9"
After the rsync copy completes, I run a find script to compare the
filesystem structure of the source and destination filesystems, note
that only the structure is compared, not the data that it contains.
I get the following discrepancy from the find script,
--- /fs/tmpfs0/2010-11-21-0614_48.cp_rt_bk3.sda6.sls 2010-11-21
06:17:42.748567092 -0500
+++ /fs/tmpfs0/2010-11-21-0614_48.cp_rt_bk3.sdb9.sls 2010-11-21
06:17:43.664551217 -0500
@@ -9454 +9454 @@
-f 0755 2 0 0 30652 1223868815.0000000000 ./sbin/e2label
+f 0755 3 0 0 30652 1223868815.0000000000 ./sbin/e2label
@@ -9458 +9458 @@
-f 0755 1 0 0 4036 1285746790.0000000000 ./sbin/findfs
+f 0755 3 0 0 30652 1223868815.0000000000 ./sbin/findfs
@@ -9573 +9573 @@
-f 0755 2 0 0 30652 1223868815.0000000000 ./sbin/tune2fs
+f 0755 3 0 0 30652 1223868815.0000000000 ./sbin/tune2fs
As one can see, "/sbin/findfs" has been incorrectly hard linked by rsync to
"/sbin/e2label" and "/sbin/tune2fs". Since the find script does not show the
inodes, here is a normal "ls" listing, taken after the system was brought to
runlevel 2,
# ls -il {,/fs/p/sdb9}/sbin/{e2label,findfs,tune2fs}
56919 -rwxr-xr-x 3 root root 30652 Oct 12 2008 /fs/p/sdb9/sbin/e2label
56919 -rwxr-xr-x 3 root root 30652 Oct 12 2008 /fs/p/sdb9/sbin/findfs
56919 -rwxr-xr-x 3 root root 30652 Oct 12 2008 /fs/p/sdb9/sbin/tune2fs
170746 -rwxr-xr-x 2 root root 30652 Oct 12 2008 /sbin/e2label
170953 -rwxr-xr-x 1 root root 4036 Sep 29 03:53 /sbin/findfs
170746 -rwxr-xr-x 2 root root 30652 Oct 12 2008 /sbin/tune2fs
I have been making these partition backup copies using rsync for some time,
without any discrepancies occurring. Then I put many new files into the
source "/" partition (the Linux kernel source tree) , and that is when the
above discrepancy first occurred.
I actually have 3 backup partitions - sdb6, sda9, and sdb9. Since I was
primarily concerned with integrity of the "/" backup copies, I re-made the
backup copies on sdb6 and sda9 using a clean (mkfs.ext3) destination filesystem
and pax (att-ast), which also failed the find script discrepancy check, but in
only a minor way by changing symlinks of the form,
a -> ./b
to
a -> b
Now this is important - then I ran the rsync backups again to sdb6 and sda9,
which cleaned up the pax symlink discrepancies, but rsync did *not* re-create
the discrepancy that I have described above.
Then I ran the rsync backup again to sdb9, and the discrepancy as described
above again occurred just as described above. So, maybe the copying of the
Linux kernel was only incidental to the hard link discrepancy.
Thanks,
Jeffrey Sheinberg
-- System Information:
Debian Release: squeeze/sid
APT prefers proposed-updates
APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages rsync depends on:
ii base-files 5.9 Debian base system miscellaneous f
ii libacl1 2.2.47-2 Access control list shared library
ii libc6 2.11.2-6+squeeze1 Embedded GNU C Library: Shared lib
ii libpopt0 1.14-4 lib for parsing cmdline parameters
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
rsync recommends no packages.
Versions of packages rsync suggests:
ii openssh-client 1:5.5p1-5+b1 secure shell (SSH) client, for sec
ii openssh-server 1:5.5p1-5+b1 secure shell (SSH) server, for sec
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
