Re: dar complains when creating decremental backup
Denis Corbin <[email protected]>
| Newsgroups | gmane.comp.sysutils.backup.dar.support |
|---|---|
| Organization | http://dar.linux.free.fr/ |
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 25/08/2019 16:02, Matus UHLAR - fantomas wrote: >>>> On 31/07/2019 19:44, Matus UHLAR - fantomas wrote: [...] > > On 04.08.19 21:01, Denis Corbin wrote: >> looking at source code, this message is issued if the file "to >> be added" (from -@ archive) has no EA or no FSA while the one "in >> place" (from -A archive) has some EA or FSA respectively. > > could it be that this message is issued when file "to be added" has > no EA or FSA, even when the file in archive also does not? Normally no, the archive you've created as you show below contains FSA > > I have created all archives like this: > > % dar -c ~/mcbackup/moj\ svet\ novovytvoreny\ 1.8.9-FULL20190825 -g > moj\ svet\ novovytvoreny\ 1.8.9/ Warning: using insecure memory! > > > -------------------------------------------- 231 inode(s) saved > including 0 hard link(s) treated 0 inode(s) changed at the moment > of the backup and could not be saved properly 0 byte(s) have been > wasted in the archive to resave changing files 0 inode(s) with only > metadata changed 0 inode(s) not saved (no inode/file change) 0 > inode(s) failed to be saved (filesystem error) 0 inode(s) ignored > (excluded by filters) 0 inode(s) recorded as deleted from reference > backup -------------------------------------------- Total number of > inode(s) considered: 231 > -------------------------------------------- EA saved for 0 > inode(s) FSA saved for 231 inode(s) so as stated above there is 231 inode in the archive each having an FSA (no EA). If you want to exclude FSA from tha backup just filter them out adding - --fsa-scope none > >> This situation may be normal (all EAs have been cleared for a >> given file for example) in which case this warning can be ignored >> and the use of -w is OK. >> >> However, I would double check first that there is nothing weird >> in the way EA and FSA are saved: just list both archive, if you >> can find some file with EA some other with FSA saved in both, >> there should not be any problem. > > I don't think I ever created or touched EA on files. you don't need to creat FSA for them to exist... it depends on filesystem: ext2/3/4 and HFS+ filesystem has FSA dar is able to save and restore, so it does by default. For example under ext2/3/4, the "nodump" flag is either set or not for a file, dar saves this status (flag is set or not). At restoration time it tries to restore it (if saved) But if the restoration occurs on an existing file that already has an FSA it will warn the user. This is what you get. You can also ignore FSA at restoration time (--fsa-scope none) dar will then not try to restore them. > I got this % dar -+ /tmp/'moj svet novovytvoreny > 1.8.9-DECR20190729-20190825' -A 'moj svet novovytvoreny > 1.8.9-FULL20190729' -@ 'moj svet novovytvoreny 1.8.9-FULL20190825' > -ad Warning: using insecure memory! EA and FSA of file <ROOT>/moj > svet novovytvoreny 1.8.9 are about to be dropped from the archive > and marked as already saved, proceed? [return = YES | Esc = NO] > Continuing... EA and FSA of file <ROOT>/moj svet novovytvoreny > 1.8.9/level.dat are about to be dropped from the archive and marked > as already saved, proceed? [return = YES | Esc = NO] > > the 'moj svet novovytvoreny 1.8.9-FULL20190729' in -A is exactly > the same file as the one used in -@ before, so I believe there are > no EAs there. the 'getfattr -R .' showed no EAs too. > [...] Cheers, Denis -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl1kF/YACgkQCDGwvQPY sYKjLg//W2ItyryZabrbiVB4ylZT+oPb/OqdNFF4+muh2AjWnJntPigRZntIg0KZ eQ4SMHYAWYWFmFaBHqprso48JcwVsgLrH+bdhROKKFRjybjwkCjoJE+cs9j1oEHu herZTOSd1TOLJYbZd8Gk6InbqG9MbtuOjzwjtwNQT8I08/FzqwwTb/nJn/vv70zs LsV3JaAfFrSxcMigtd13MWWShDbmiP6DaDM3OHoTKWCstZ9TOr01ntO6I2i7ygol s6icoNpZG64kE98roywV4Ra410IBCnZNvr9yz5IHh687RkYuTgoPu3ikGi/TjZok 8kdZ/Oclyz0yEU0Vm1sza05uJOI9oVKV7A9VMylQZdJt5MKXuiszLsv14CEQ/2/+ KPvFx1xLjVI3XTwD9Qn89o6XP5FnaICp/c2XmVw9n9ELsD9+UrasME4pP3Di97WJ /ftFn/giTHZQY/5g+3EukLbnNYZisOEFI3SlWzoARYYWKgB1FcCS9Ck7xs0pcSb7 8o3At6M2oli8AZN/ymIDNgB6XdqrGBmmGWtyz91c1hsIYhXsHO/0qG3zt9atC7dx RUZtH0wAYLnc3vvbrJ9VBn5NtZ4PPqoz9tSuOfubcHnWbG90gsHhYCKCrEZmSjFL ObluVG8pV2BvywyqiKJ4hdcqzBwp293Ybj+wv70g6uv52i5JPEo= =8G3j -----END PGP SIGNATURE-----