[opensuse] Problem with rsync and hardlinks
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have an image of a disk that contains backups done with rsync, done originally this way: +++............. PREVIO=/run/media/linux/Erebor_2/Portatil_entero_6 DESTINO=/run/media/linux/Erebor_2/Portatil_entero_7 OPTIONS="--archive --acls --xattrs --hard-links --sparse --stats --human-readable --checksum" rsync $OPTIONS --link-dest=$PREVIO/rsync_root /run/media/linux/Root/ $DESTINO/rsync_root .............++- It worked. Example: +++............. localhost:/data/Datum/mountpoint # l Portatil_entero_?/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip localhost:/data/Datum/mountpoint # .............++- ^ It is the same file, and the "2" is indicative of being hardlinks, I believe. But when I copy all that to another disk using rsync and telling I want to keep hardlinks, they are not. +++............. OPTIONS="--archive --acls --xattrs --hard-links --sparse --partial-dir=.rsync-partial --stats --human-readable" time rsync $OPTIONS root@telcontar.valinor://data/Datum/mountpoint/Portatil_entero_7/ /data/Portatil_entero_7 time rsync $OPTIONS root@telcontar.valinor://data/Datum/mountpoint/Portatil_entero_6/ /data/Portatil_entero_6 .............++- I get: +++............. Erebor:/data # l Portatil_entero_?/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip Erebor:/data # .............++- The "1" indicate they are real files both, not hardlinks one to the other. Why, what did I do wrong? - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCX4a7VRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVTWsAnRbdmPZ8jEr1j6zkUiiS J4Irk+/aAJwM8EkB3jZb+NZTBn9wwpYuRiDzeQ== =c4vI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 14 Oct 2020 10:48:20 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I have an image of a disk that contains backups done with rsync, done originally this way:
+++............. PREVIO=/run/media/linux/Erebor_2/Portatil_entero_6 DESTINO=/run/media/linux/Erebor_2/Portatil_entero_7
OPTIONS="--archive --acls --xattrs --hard-links --sparse --stats --human-readable --checksum"
rsync $OPTIONS --link-dest=$PREVIO/rsync_root /run/media/linux/Root/ $DESTINO/rsync_root .............++-
It worked. Example:
+++............. localhost:/data/Datum/mountpoint # l Portatil_entero_?/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip localhost:/data/Datum/mountpoint # .............++-
^
It is the same file, and the "2" is indicative of being hardlinks, I believe.
I think that's correct.
But when I copy all that to another disk using rsync and telling I want to keep hardlinks, they are not.
+++............. OPTIONS="--archive --acls --xattrs --hard-links --sparse --partial-dir=.rsync-partial --stats --human-readable"
time rsync $OPTIONS root@telcontar.valinor://data/Datum/mountpoint/Portatil_entero_7/ /data/Portatil_entero_7 time rsync $OPTIONS root@telcontar.valinor://data/Datum/mountpoint/Portatil_entero_6/ /data/Portatil_entero_6 .............++-
I get:
+++............. Erebor:/data # l Portatil_entero_?/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip Erebor:/data # .............++-
The "1" indicate they are real files both, not hardlinks one to the other.
I think that's also correct. I expect there's a way to check by listing numerical IDs instead of filenames or somesuch, depending on the filesystem.
Why, what did I do wrong?
Probably silly question, but what's the filesystem structure? i.e. it is possible to make hard links between those two directories, isn't it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/10/2020 11.38, Dave Howorth wrote:
On Wed, 14 Oct 2020 10:48:20 +0200 (CEST) "Carlos E. R." <> wrote:
...
I get:
+++............. Erebor:/data # l Portatil_entero_?/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip Erebor:/data # .............++-
The "1" indicate they are real files both, not hardlinks one to the other.
I think that's also correct. I expect there's a way to check by listing numerical IDs instead of filenames or somesuch, depending on the filesystem.
Ah, rings a bell... original: cer@Telcontar:~> ls -ltr --inode /data/Datum/mountpoint/Portatil_entero_?/rsync_Home/cer/spamassassin.zip 1442217551 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 /data/Datum/mountpoint/Portatil_entero_7/rsync_Home/cer/spamassassin.zip 1442217551 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 /data/Datum/mountpoint/Portatil_entero_6/rsync_Home/cer/spamassassin.zip cer@Telcontar:~> copy: Erebor:/data # ls -ltr --inode Portatil_entero_?/rsync_Home/cer/spamassassin.zip 66229 -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip 939879 -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip Erebor:/data # Yes, the original backup have the same inode.
Why, what did I do wrong?
Probably silly question, but what's the filesystem structure? i.e. it is possible to make hard links between those two directories, isn't it?
Yes, the directories are in the same partition and filesystem. The original is XFS, the destination is btrfs Erebor:/data # touch test Erebor:/data # ln test test2 Erebor:/data # ls -ltr --inode test* 1712666 -rw-r--r-- 2 root root 0 Oct 14 11:48 test2 1712666 -rw-r--r-- 2 root root 0 Oct 14 11:48 test Erebor:/data # Verified. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, 14 Oct 2020 11:50:43 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 14/10/2020 11.38, Dave Howorth wrote:
On Wed, 14 Oct 2020 10:48:20 +0200 (CEST) "Carlos E. R." <> wrote:
...
I get:
+++............. Erebor:/data # l Portatil_entero_?/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip - -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip Erebor:/data # .............++-
The "1" indicate they are real files both, not hardlinks one to the other.
I think that's also correct. I expect there's a way to check by listing numerical IDs instead of filenames or somesuch, depending on the filesystem.
Ah, rings a bell...
original:
cer@Telcontar:~> ls -ltr --inode /data/Datum/mountpoint/Portatil_entero_?/rsync_Home/cer/spamassassin.zip 1442217551 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 /data/Datum/mountpoint/Portatil_entero_7/rsync_Home/cer/spamassassin.zip 1442217551 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 /data/Datum/mountpoint/Portatil_entero_6/rsync_Home/cer/spamassassin.zip cer@Telcontar:~>
copy:
Erebor:/data # ls -ltr --inode Portatil_entero_?/rsync_Home/cer/spamassassin.zip 66229 -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip 939879 -rw-r--r-- 1 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip Erebor:/data #
Yes, the original backup have the same inode.
Why, what did I do wrong?
Probably silly question, but what's the filesystem structure? i.e. it is possible to make hard links between those two directories, isn't it?
Yes, the directories are in the same partition and filesystem. The original is XFS, the destination is btrfs
Erebor:/data # touch test Erebor:/data # ln test test2 Erebor:/data # ls -ltr --inode test* 1712666 -rw-r--r-- 2 root root 0 Oct 14 11:48 test2 1712666 -rw-r--r-- 2 root root 0 Oct 14 11:48 test Erebor:/data #
Verified.
OK, the manual says: "Note that rsync can only detect hard links between files that are inside the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage will be broken." I suspect your second set of rsyncs meets that caveat and so your files are unlinked. Copy the whole lot in one transfer and it may work. I also know that rsync can create hard-links on the fly in the destination even when there's no such concept on the source side. I know because that's how my incremental full backup works. But I don't remember the full set of flags at the mo. But if you can figure out the flags, that would presumably also correct your problem. I'll look it up if you get stuck. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/10/2020 16.27, Dave Howorth wrote:
On Wed, 14 Oct 2020 11:50:43 +0200 "Carlos E. R." <> wrote:
On 14/10/2020 11.38, Dave Howorth wrote:
On Wed, 14 Oct 2020 10:48:20 +0200 (CEST) "Carlos E. R." <> wrote:
...
OK, the manual says:
"Note that rsync can only detect hard links between files that are inside the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage will be broken."
I suspect your second set of rsyncs meets that caveat and so your files are unlinked. Copy the whole lot in one transfer and it may work.
Yes, I imagined this was the case (didn't read that part of the manual) and tried again: OPTIONS="--archive --acls --xattrs --hard-links --sparse --partial-dir=.rsync-partial --stats --human-readable" time rsync $OPTIONS --exclude "sda?_root" root@telcontar.valinor://data/Datum/mountpoint/ /data/ and it worked: Erebor:/data # ls -ltr --inode Portatil_entero_?/rsync_Home/cer/spamassassin.zip 1778503 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip 1778503 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip Erebor:/data #
I also know that rsync can create hard-links on the fly in the destination even when there's no such concept on the source side. I know because that's how my incremental full backup works. But I don't remember the full set of flags at the mo. But if you can figure out the flags, that would presumably also correct your problem. I'll look it up if you get stuck.
Actually, the source tree was created that way, they are an incremental backup :-) That's why the number of hard links is significant, not copying them meant disk full on the destination. (Ie, I'm copying an incremental backup set that was done with rsync initially) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, 14 Oct 2020 17:48:24 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 14/10/2020 16.27, Dave Howorth wrote:
On Wed, 14 Oct 2020 11:50:43 +0200 "Carlos E. R." <> wrote:
On 14/10/2020 11.38, Dave Howorth wrote:
On Wed, 14 Oct 2020 10:48:20 +0200 (CEST) "Carlos E. R." <> wrote:
...
OK, the manual says:
"Note that rsync can only detect hard links between files that are inside the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage will be broken."
I suspect your second set of rsyncs meets that caveat and so your files are unlinked. Copy the whole lot in one transfer and it may work.
Yes, I imagined this was the case (didn't read that part of the manual) and tried again:
OPTIONS="--archive --acls --xattrs --hard-links --sparse --partial-dir=.rsync-partial --stats --human-readable"
time rsync $OPTIONS --exclude "sda?_root" root@telcontar.valinor://data/Datum/mountpoint/ /data/
and it worked:
Erebor:/data # ls -ltr --inode Portatil_entero_?/rsync_Home/cer/spamassassin.zip 1778503 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip 1778503 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip Erebor:/data #
I also know that rsync can create hard-links on the fly in the destination even when there's no such concept on the source side. I know because that's how my incremental full backup works. But I don't remember the full set of flags at the mo. But if you can figure out the flags, that would presumably also correct your problem. I'll look it up if you get stuck.
Actually, the source tree was created that way, they are an incremental backup :-) That's why the number of hard links is significant, not copying them meant disk full on the destination.
(Ie, I'm copying an incremental backup set that was done with rsync initially)
Ah well, I'm glad you got it sorted and I'm glad it was you that found this little wrinkle rather than me :) I'll try to remember to copy the whole incremental backup in one shot if/when I need to. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2020-10-14 at 20:22 +0100, Dave Howorth wrote:
On Wed, 14 Oct 2020 17:48:24 +0200 "Carlos E. R." <> wrote:
On 14/10/2020 16.27, Dave Howorth wrote:
On Wed, 14 Oct 2020 11:50:43 +0200 "Carlos E. R." <> wrote:
On 14/10/2020 11.38, Dave Howorth wrote:
On Wed, 14 Oct 2020 10:48:20 +0200 (CEST) "Carlos E. R." <> wrote:
...
I also know that rsync can create hard-links on the fly in the destination even when there's no such concept on the source side. I know because that's how my incremental full backup works. But I don't remember the full set of flags at the mo. But if you can figure out the flags, that would presumably also correct your problem. I'll look it up if you get stuck.
Actually, the source tree was created that way, they are an incremental backup :-) That's why the number of hard links is significant, not copying them meant disk full on the destination.
(Ie, I'm copying an incremental backup set that was done with rsync initially)
Ah well, I'm glad you got it sorted and I'm glad it was you that found this little wrinkle rather than me :) I'll try to remember to copy the whole incremental backup in one shot if/when I need to.
Yep. I'm happy now :-D But I wasn't 5 minutes ago. I was doing the backup on this migrated backup disk, had been running for an hour, I saw hard disk free space disapearing, and I noticed that hardlinks were not being made (rsync - --link-dest=... stuff). cer@Erebor:~> l /data/Portatil_entero_?/minas-tirith/home/cer/w - -rw------- 2 cer users 24119460 May 7 2015 /data/Portatil_entero_6/minas-tirith/home/cer/w - -rw------- 2 cer users 24119460 May 7 2015 /data/Portatil_entero_7/minas-tirith/home/cer/w - -rw------- 1 cer users 24119460 May 7 2015 /data/Portatil_entero_8/minas-tirith/home/cer/w You see, #6 and #7 are the old backups (migrated to new hd), showing a hardlinked file. But on the new incremental backup, #8, the file was a new file. This was wrong. I was doing: # PREVIO=/data/Portatil_entero_7 # DESTINO=/data/Portatil_entero_8 # source: /mnt/minas-tirith # previous: /data/Portatil_entero_7/minas-tirith # destination: /data/Portatil_entero_8/minas-tirith time rsync $OPTIONS --link-dest=$PREVIO/minas-tirith \ --exclude=/mnt/minas-tirith/run/media/linux/Home/_var_spool_news \ --exclude=/_var_spool_news \ --exclude=_var_spool_news \ --exclude=/mnt/minas-tirith/run/media/linux/Home/_var_spool_news.cpy \ --exclude=/_var_spool_news.cpy \ --exclude=_var_spool_news.cpy \ /mnt/minas-tirith /$DESTINO I corrected to: # fuente: /mnt/minas-tirith # previo: /data/Portatil_entero_7/minas-tirith # destino: /data/Portatil_entero_8/minas-tirith time rsync $OPTIONS --link-dest=$PREVIO/minas-tirith \ --exclude=/mnt/minas-tirith/run/media/linux/Home/_var_spool_news \ --exclude=/_var_spool_news \ --exclude=_var_spool_news \ --exclude=/mnt/minas-tirith/run/media/linux/Home/_var_spool_news.cpy \ --exclude=/_var_spool_news.cpy \ --exclude=_var_spool_news.cpy \ /mnt/minas-tirith/ $DESTINO/minas-tirith changed..............^.........^^^^^^^^^^^^^ And: cer@Erebor:~> ls -l --inode /data/Portatil_entero_?/minas-tirith/captura-thomson 1959625 -rw------- 3 root root 54944 Jul 7 2013 /data/Portatil_entero_6/minas-tirith/captura-thomson 1959625 -rw------- 3 root root 54944 Jul 7 2013 /data/Portatil_entero_7/minas-tirith/captura-thomson 1959625 -rw------- 3 root root 54944 Jul 7 2013 /data/Portatil_entero_8/minas-tirith/captura-thomson cer@Erebor:~> cer@Erebor:~> l --inode /data/Portatil_entero_?/minas-tirith/home/cer/w 1778507 -rw------- 3 cer users 24119460 May 7 2015 /data/Portatil_entero_6/minas-tirith/home/cer/w 1778507 -rw------- 3 cer users 24119460 May 7 2015 /data/Portatil_entero_7/minas-tirith/home/cer/w 1778507 -rw------- 3 cer users 24119460 May 7 2015 /data/Portatil_entero_8/minas-tirith/home/cer/w cer@Erebor:~> 3 backup sets, 3 hard links. I'm happy :-D (wow, rsync syntax _is_ critical) (And I have just discovered an error in the --exclude section, but it is working anyway) - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCX4ePzhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVjR8An26mzzczV07FgrXCJYA2 Sd59vW/vAJ9pauww95LIN4ZiVjNMygGAe8DjRw== =ayk4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/10/2020 01.54, Carlos E. R. wrote: ...
cer@Erebor:~> l --inode /data/Portatil_entero_?/minas-tirith/home/cer/w 1778507 -rw------- 3 cer users 24119460 May 7 2015 /data/Portatil_entero_6/minas-tirith/home/cer/w 1778507 -rw------- 3 cer users 24119460 May 7 2015 /data/Portatil_entero_7/minas-tirith/home/cer/w 1778507 -rw------- 3 cer users 24119460 May 7 2015 /data/Portatil_entero_8/minas-tirith/home/cer/w cer@Erebor:~>
3 backup sets, 3 hard links. I'm happy :-D
before: er@Erebor:~> df -h /data Filesystem Size Used Avail Use% Mounted on /dev/mapper/cr_data 915G 639G 275G 70% /data cer@Erebor:~> Now, with backup done (one backup is 282314M): cer@Erebor:~> df -h /data Filesystem Size Used Avail Use% Mounted on /dev/mapper/cr_data 915G 669G 247G 74% /data cer@Erebor:~> I still have 247G free - hardlinks at work :-D -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
participants (2)
-
Carlos E. R. -
Dave Howorth