Hi,
now it's time to come back to this topic.
As supposed, the missing hardlinks where no issue of rsync. I am not sure
if pairing aufs (http://aufs.sourceforge.net/) and rsync -RH will catch
each and every hardlink compared to a single filesystem, but it seems to
work very reliable.
I tried mhdfs and aufs. Aufs is faster and very stable (I am on wheezy
kernel 3.2).
So at last I have my solution to get several harddisks into a big one in
order to use rsync to do my offsite backup.
Why aufs and not LVM/Raid:
1) I don't want to loose all data of the backup set if one device gets
errors.
2) I use the feature to add or remove space and can do so by changing ONE
disk ... all other keep their data of the backup set. Next time rsync aud
aufs "recover" only the files which where on the replaced drive.
If anyone has any questions or comments or wishes to test, please feel free
.. please cc (lopiuh at gmail dot com) because I could miss mailing list
entries.
Here are the relevant commands I use:
mount -t aufs -o br=/mnt/mp_drive1=rw:/mnt/mp_drive2=rw:/mnt/mp_drive3=rw
-o sum -o create=mfs -o udba=none none /mnt/aufs
cd srcdir_parrent
nice -n 19 ionice -c3 rsync -RavhSDHi --stats --del srcdir_1 srcdir_2
srcdir_3 /mnt/aufs/
Thanks Kevin for helping me this time and at that time
lopiuh
*Fri Aug 2 17:52:55 MDT 2013*
*I wrote:*
Ok, dest is on aufs (with 5 isolated harddisks and ext4-filesystems
being> joined together). src2 gets on a different target device at the aufs end.
> So it cant't be hardlinked. Normaly aufs seems to be clever with
hardlinks
> but in my case the device src1 is located on dest is full and aufs seems to
> say src2 will be located on a different target device and therfore
can't be
> hardlinked to src1 (on dest).
> Interestingly this not visible to rsync (there is not that
"==>" whiich
> would show rsync is hardlinking. I will do some more tests and try to
> validate these thoughts. Afterwords I will probably reevaluate aufs for
> this usecase ;-)
> Kevin, thanks for being with me. I will come back and report my findings
> with aufs and -R rsync .During the initial rsync job (without -R which
> copied src1 to dest) it was very clever and populated all hardlinks in src1
> even with spreading the files on 5 harddisks.
> The second rsync job (introducing src2) seems to get aufs in trouble
> because aufs locates src2/b not on the same device where src1/a is located.
> Tricky tricky
> Comming back soon...
> Lopiuh
>
On Sat, Aug 3, 2013 at 1:30 AM, - <lopiuh at googlemail.com> wrote:
> could be aufs (on dest) I do some tests now.
>
> source is identical:
>
> root at mediapc:/mnt/foo/server_gen# stat
>
/mnt/hotswapo/storebackup/server_gen/2013.07.26_03.08.38/\$sortin_linux/natty_lirc_work/etc/fuse.conf> File:
>
`/mnt/hotswapo/storebackup/server_gen/2013.07.26_03.08.38/$sortin_linux/natty_lirc_work/etc/fuse.conf'> Size: 216 Blocks: 8 IO Block: 131072 regular file
> Device: 17h/23d Inode: 219420238 Links: 124
> Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2013-08-02 23:42:19.959015277 +0200
> Modify: 2011-02-10 22:03:08.000000000 +0100
> Change: 2013-08-02 03:19:01.487305400 +0200
> Birth: -
>
> root at mediapc:/mnt/foo/server_gen# stat
>
/mnt/hotswapo/storebackup/server_gen/2013.07.27_03.08.46/\$sortin_linux/natty_lirc_work/etc/fuse.conf> File:
>
`/mnt/hotswapo/storebackup/server_gen/2013.07.27_03.08.46/$sortin_linux/natty_lirc_work/etc/fuse.conf'> Size: 216 Blocks: 8 IO Block: 131072 regular file
> Device: 17h/23d Inode: 219420238 Links: 124
> Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2013-08-02 23:42:19.959015277 +0200
> Modify: 2011-02-10 22:03:08.000000000 +0100
> Change: 2013-08-02 03:19:01.487305400 +0200
> Birth: -
>
>
> Greetings
>
>
> On Sat, Aug 3, 2013 at 1:25 AM, Kevin Korb <kmk at sanitarium.net>
wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Can you do a stat on both of the source file and confirm that they
>> have matching device numbers as well as inode numbers?
>>
>> On 08/02/13 19:22, - wrote:
>> > Hi,
>> >
>> > no same mountpoints. And doing a "synthetic" test (two
new
>> > directories) it works, even in the same simulated steps. (first
>> > sync dir1, then ad link after that sync dir1 and dir2 to dest
(dir2
>> > is added to dest)
>> >
>> > not so on my "real" data
>> >
>> > Here is a file of "production" data::: src1:
>> >
>> > ls -li
>> >
>>
/mnt/hotswapo/storebackup/server_gen/2013.07.26_03.08.38/\$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> >
>> 219420238 -rw-r----- 124 root root 216 Feb 10 2011
>> >
>>
/mnt/hotswapo/storebackup/server_gen/2013.07.26_03.08.38/$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> > src2: ls -li
>> >
>>
/mnt/hotswapo/storebackup/server_gen/2013.07.27_03.08.46/\$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> >
>> 219420238 -rw-r----- 124 root root 216 Feb 10 2011
>> >
>>
/mnt/hotswapo/storebackup/server_gen/2013.07.27_03.08.46/$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> > ->same inode (219420238)
>> >
>> > doing the sync
>> >
>> > rsync -RavhxSDHi --stats --progress server_gen/2013.07.27_03.08.46
>> > server_gen/2013.07.26_03.08.38 /mnt/foo/
>> >
>> > checking results:
>> >
>> > lroot at mediapc:/mnt/foo/server_gen# ls -li
>> >
>>
/mnt/foo/server_gen/2013.07.26_03.08.38/\$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> >
>> 868354 -rw-r----- 1 root root 216 Feb 10 2011
>> >
>>
/mnt/foo/server_gen/2013.07.26_03.08.38/$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> > root at mediapc:/mnt/foo/server_gen# ls -li
>> >
>>
/mnt/foo/server_gen/2013.07.27_03.08.46/\$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> >
>> 6523 -rw-r----- 2 root root 216 Feb 10 2011
>> >
>>
/mnt/foo/server_gen/2013.07.27_03.08.46/$sortin_linux/natty_lirc_work/etc/fuse.conf>> >
>> > result: different inodes, not hardlinked
>> >
>> > Greetings
>> >
>> >
>> >
>> >
>> > On Sat, Aug 3, 2013 at 1:05 AM, Kevin Korb <kmk at
sanitarium.net
>> > <mailto:kmk at sanitarium.net>> wrote:
>> >
>> > Oooops, I replied but I didn't reply to the list...
>> >
>> > Are the two sources on different NFS mounts? If they are are hard
>> > links then obviously they are on the same file system on the
>> > server but if the NFS client has them in 2 different mounts rsync
>> > would probably not realize that they are linked together.
>> >
>> > On 08/02/13 19:03, - wrote:
>> >
>> >> Hi,
>> >
>> >> ok did a sample test like your test and it worked. But using
my
>> >> real directories (roughly a million files) it does not work.
>> >> Never had problems before with hardlinking.
>> >
>> >> Is there anything I could do to narrow down the problem?
>> >> (Version 3.0.9 on wheezy 64bit)
>> >
>> >> source is on NFS, dest is on AUFS (could be problematic) but
the
>> >> small sample like you did was perfectly fine. I used same
>> >> options and path scheme in both tests.
>> >
>> >> Thanks
>> >
>> >> lopiuh
>> >
>> >
>> >> On Sat, Aug 3, 2013 at 12:14 AM, Kevin Korb <kmk at
sanitarium.net
>> > <mailto:kmk at sanitarium.net>
>> >> <mailto:kmk at sanitarium.net <mailto:kmk at
sanitarium.net>>> wrote:
>> >
>> >> # ls -li /tmp/src?/testfile 3349750 -rw-r--r-- 2 root root 0
Aug
>> >> 2 18:12 /tmp/src1/testfile 3349750 -rw-r--r-- 2 root root 0
Aug
>> >> 2 18:12 /tmp/src2/testfile # rsync -RvaiH /tmp/src1 /tmp/src2
>> >> /tmp/target sending incremental file list created directory
>> >> /tmp/target cd+++++++++ /tmp/ cd+++++++++ /tmp/src1/
cd+++++++++
>> >> /tmp/src2/
>> >>> f+++++++++ /tmp/src2/testfile
>> >> hf+++++++++ /tmp/src1/testfile => tmp/src2/testfile
>> >
>> >> sent 192 bytes received 68 bytes 520.00 bytes/sec total size
is
>> >> 0 speedup is 0.00 # ls -li /tmp/target/tmp/src?/testfile
3351917
>> >> -rw-r--r-- 2 root root 0 Aug 2 18:12
>> >> /tmp/target/tmp/src1/testfile 3351917 -rw-r--r-- 2 root root 0
>> >> Aug 2 18:12 /tmp/target/tmp/src2/testfile
>> >
>> >
>> >> On 08/02/13 18:11, Kevin Korb wrote:
>> >>> It works for me in 3.0.9. Are you on an older version?
>> >
>> >>> On 08/02/13 18:08, - wrote:
>> >>>> Hi,
>> >
>> >>>> hardlinking (-H) works perfectly while using a syntax
like
>> >>>> -avhxSDH <SRC> <DEST>
>> >
>> >>>> Now I have to mirror multiple SRC directories which
contain
>> >>>> hardlinks. e. g: src1/a is a hardlink to src2/b
>> >
>> >>>> -RavhxSDH SRC1 SRC2 DEST
>> >
>> >>>> does not preserve hardlink a and b in DEST. Is there
any
>> >>>> chance to do that?
>> >
>> >>>> Thanks
>> >
>> >>>> lopiuh
>> >
>> >
>> >
>> >
>> >
>> >> -- Please use reply-all for most replies to avoid omitting the
>> >> mailing list. To unsubscribe or change options:
>> >> https://lists.samba.org/mailman/listinfo/rsync Before posting,
>> >> read: http://www.catb.org/~esr/faqs/smart-questions.html
>> >
>> >
>> >
>> >
>> >
>> >
>> > -- Please use reply-all for most replies to avoid omitting the
>> > mailing list. To unsubscribe or change options:
>> > https://lists.samba.org/mailman/listinfo/rsync Before posting,
>> > read: http://www.catb.org/~esr/faqs/smart-questions.html
>> >
>> >
>>
>> - --
>>
>>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~>> Kevin Korb Phone: (407) 252-6853
>> Systems Administrator Internet:
>> FutureQuest, Inc. Kevin at FutureQuest.net
(work)
>> Orlando, Florida kmk at sanitarium.net
(personal)
>> Web page: http://www.sanitarium.net/
>> PGP public key available on web site.
>>
>>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.20 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iEYEARECAAYFAlH8P+MACgkQVKC1jlbQAQd5bgCghdn2lonMX6UB4vL2Y6T3xEzx
>> GqwAoK1Lt3h6O6rNhcbCAHO+Ja7o0UzV
>> =FFbQ
>> -----END PGP SIGNATURE-----
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20131202/06a1c8e5/attachment.html>
