Re: [Dar-support] MAYBE BUG in dar 2.7.2 with hardlinks handling
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
Menu
▾
▴
Re: [Dar-support] MAYBE BUG in dar 2.7.2 with hardlinks handling
|
From: Alexey L. <moo...@ma...> - 2021-12-08 11:14:55
|
On 04.12.2021 20:39, Denis Corbin wrote: > I'm not sure to follow what you plan to do, but I guess it is > possible... Based on your answers I guess that you are probably missing the main point of "my plan" here. Idea was to introduce a new mode of "filesystem traversal" for which we totally get rid of real FS traversing and instead get the list of files to work with from some "external source". Then we apply filters in usual manner based on include/exclude rules, e.t.c., e.t.c. Expected use pattern would look like this: # find <backup root dir> <filtering options> | sort -u > file-list-to-include-into-backup.txt # dar -R <backup root dir> --files-to-consider-list file-list-to-include-into-backup.txt -c <new backup name> -A <previous backup> ..... This way user would be in the full control of the ordering of files to backup thus it would be possible to make sure that files from "older" subdirectory would come in front of files from "new" subdir when applied to my failing use case described in earlier message. > I tried playing with the merging operation ... If the new backup do > not contain the old hardlinked inodes, at restoration time, the hard > links may not be restored (the hard link is missing in the restored > directory): this is because the order in which the directory content > was returned by the operating system is kept in the backup... Tried to do the same and observation is that for hardlink to be restored two conditions should be met: 1. Target file to hardlink to should exist. 2. Archive entry pointing to the target file to be hardlinked to (i.e. one that is not "[Saved]" and is inside a dir that is not "[Saved]" too) should come before any other entry which is a hardlink to the same inode residing in a dir that is "[Saved]". Let me illustrate with an example. Given is that we have file named "79/abc.txt" in place on the disk. Then with archive looking like this: [Data ][D][ EA ][FSA][Compr][S]| Permission | User | Group | Size | Date | filename --------------------------------+------------+-------+-------+---------+-------------------------------+------------ [ ][-] [---][ ][ ] drwxr-xr-x root root 0 Fri Dec 3 02:14:30 2021 79 [ ][ ] [---][-----][ ] *-rw-r--r-- root root 15 kio Fri Dec 3 02:14:30 2021 79/abc.txt [0] [Saved][-] [---][ ][ ] drwxr-xr-x root root 0 Fri Dec 3 02:14:30 2021 80 [ ][ ] [---][-----][ ] *-rw-r--r-- root root 15 kio Fri Dec 3 02:14:30 2021 80/abc.txt [0] ... hardlink 80/abc.txt will be restored. But in case the archive lists like this: [Data ][D][ EA ][FSA][Compr][S]| Permission | User | Group | Size | Date | filename --------------------------------+------------+-------+-------+---------+-------------------------------+------------ [Saved][-] [---][ ][ ] drwxr-xr-x root root 0 Fri Dec 3 02:14:30 2021 80 [ ][ ] [---][-----][ ] *-rw-r--r-- root root 15 kio Fri Dec 3 02:14:30 2021 80/abc.txt [0] [ ][-] [---][ ][ ] drwxr-xr-x root root 0 Fri Dec 3 02:14:30 2021 79 [ ][ ] [---][-----][ ] *-rw-r--r-- root root 15 kio Fri Dec 3 02:14:30 2021 79/abc.txt [0] ... then hardlink won't be restored. In your experiments at least one or both of conditions listed above were not met due to the ordering of the entries in the archive which was determined by the initial ordering at creation time matching the order filesystem traversal was done by the OS. It won't be the case for " filelist-based backup approach" described above as entry order would be warranted to be predictable and stable thanks to manual efforts taken to sort (and manipulate in any other way required) the list of files/directories to be backed up. -- Regards, Alexey Loukianov System Engineer *nix Expert |
