William Kenworthy wrote: > > On 22/10/23 11:23, Dale wrote: >> Frank Steinmetzger wrote: >>> Am Fri, Oct 20, 2023 at 09:20:45PM -0500 schrieb Dale: >>>> Howdy, >>>> >>>> As most know, I had to restore from backups recently. I also reworked >>>> my NAS box. I'm doing my first backup given that I have more files >>>> that >>>> need to be added to the backups. When I started the rsync, it's >>>> starting from the first file and updating each file as it goes as >>>> if all >>>> of them changed. Given that likely 95% of the files hasn't changed, I >>>> figure this is being done because of a time stamp or something. Is >>>> there a way to tell rsync to ignore the time stamp or something or if >>>> the files are the same size, just update the time stamp? Is there >>>> a way >>>> to just update the time stamps on the NAS box? Is there a option I >>>> haven't thought of to work around this? >>>> >>>> This is the old command I was using to create the backups. >>>> >>>> time rsync -uivr --progress --delete >>>> /home/dale/Desktop/Crypt/TV_Series >>>> /mnt/TV_Backup/ >>> This didn’t preserve timestamps. Hence there is one type of >>> information lost >>> from which rsync knows whether two files may be identical. So now your >>> restore has more recent timestamps the the backup. If you use -u, Rsync >>> should skip all files. >>> >>> My perfectionist self doesn’t like discarding timestamp information, >>> because >>> then my system can’t tell me how old some file is, and how old (or >>> young) I >>> was when I created it and so on. I once didn’t pay enough attention >>> when >>> restoring a backup back when I was still on Windows, which is why I >>> don’t >>> have many files left that are dated before April 2007, even though >>> they are >>> from 2000 ± x. >>> >>> BTW: -i and -v are redundant. -v will only print the file path, >>> whereas -i >>> does the same and adds the reasons colum at the beginning. >>> >>>> I tried these to try to get around it. >>>> >>>> time rsync -ar --progress --delete >>>> /home/dale/Desktop/Crypt/TV_Series /mnt/TV_Backup/ >>> -a and -r are also redundant, as -a includes -r. >>> >>>> I looked at the man page and the options there. I don't see anything >>>> that I think will help. Is there a way around this? >>> My muscle memory uses `rsync -ai` for almost everything. And when I >>> do full >>> root file systems or stuff where I know I will need them, I use -axAHX >>> instead. Since this preserves all the usual data, I’ve never really had >>> rsync wanting to do everything all over. >>> >> Well, I can't turn back the clocks so it is what it is now. These files >> tho, I really don't worry to much about the timestamps. If I were >> backing up my OS tho, that could become a problem. >> >> So my command should be more like: >> >> rsync -ai --progress --delete /path/to/source/ path/to/target >> >> If I want to preserve all the Linux file data, then I should use this: >> >> rsync -axAHX --progress --delete /path/to/source/ path/to/target >> >> Dale >> >> :-) :-) >> >> P. S. Working on new kernel for fireball. Added some options for >> encryption stuff. I really need to update to a newer kernel. I got a >> newer one that boots but no GUI. That's not very helpful. > >> Hi Dale, I might have missed it in the thread but are you aware that >> rsync is focussed on remote filefile transfer and if its a local >> transfer it does a full copy (no delta) of the file without >> optimisations as its usually faster than all the extra operations a >> local delta requires. > > You are using NFS mounts so rsync is looking at it as a local copy - > it does not know it is a remote system. > > My recent use of moosefs (another network file system) had similar > problems using rsync - it also turns out some of the data rsync uses > for detecting changes may not be stable across a network mount - > moosefs certainly has problems with this, NFS likely to have it too. > > The workaround is to check file-size, mtimes and ctimes to figure out > which is able to be used. > > see: > > http://unix.stackexchange.com/questions/450537/ddg#450666 > > google rsync over nfs > > BillK
I've read about using rsync as a daemon. It is supposed to be faster. For some reason, I just never got around to trying it. It would likely be a good idea to work on that. It would likely be really handy when moving large amounts of data. I may try to read a howto on the Gentoo wiki or something. See what all it involves. Interesting link. I find some good info on that site at times. Dale :-) :-)
