Les Mikesell wrote: > Evren Yurtesen wrote: >> >> Also I see the --ignore-times option in rsync args for full backups. Why >> is this necessary exactly? > > If you don't, you are trusting that every file that has the same name, > timestamp and length on the previous backup still matches the contents > on the target. It probably, mostly, usually, does... If you posted a > listing that showed the duration of fulls vs. incrementals, I think I > missed it, but it would show the difference in the extra > reading/comparison work on the server side. Even for incrementals you > still have to wade through the metadata for each file to find the > original length/timestamp/owner etc. which won't be the same as the > compressed/pooled file itself because those may be different for > different instances of the pooled contents.
Yes, this is causing a lot of extra processing on the server side. However most backup programs do not do this detailed file checking(I think?) and nobody seems to be complaining. There at least should be an option to only rely on the name/timestamp of a file when using rsync also. > The other side effect of doing a full - and the one you really need - is > that the complete directory structure is rebuilt as the base for > subsequent incrementals. >>> With tar, you never need to read the existing files so you are doing >>> much less work and you don't hold the remote directory in memory at all. >>> But if tar works better on your system, why not use it? The only >>> real drawback is that incremental runs won't catch old files in their >>> new positions under renamed directories. The full runs will >>> straighten this out. >>> >> >> Is it still possible to pool the files for saving disk space when >> using tar? > > Yes, there is no difference in the pool handling with any of the > transfer methods. Tar and smb just have to transfer the file contents > before it can be matched against the pool. If you have plenty of > bandwidth this will happen faster than the rsync comparison. Also, tar > and smb incrementals use only the timestamp on the target to determine > what to back up so the server doesn't have to do extra work to compare. > >> I wonder something, why cant backuppc set the backed up file >> modification times to >> match the client when backing up the files so it can compare the file >> modification >> time only at incrementals (and perhaps at full backups) like tar? In >> either case >> backuppc can do file by file checks when using rsync anyhow, but the >> limitations tar >> imposes would be removed, wouldnt it? > > Tar doesn't have a way to do live comparisons. GNUtar does have a way > to detect renamed directories, but it requires saving a file on the > target machine. > What I meant was, if tar is used then live comparisons can not be done. Tar relies on the modification time. However if rsync is used then the file location and modification time can be checked. If a file is renamed or moved keeping the same modification time then this can be detected using rsync even without checksum checks (which would give the same checksum anyway). So checksum is saving bandwidth if a file modification time is different but the contents are same. In any case, somebody else said that when checksum caching is enabled then file checksums are not calculated at it backup session by uncompressing the files. If this is true? then I can live with it but CPU usage could be lowered further if this was an option which could be disabled and better performance could be achieved. Thanks for all the help and patience! :) Evren ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ BackupPC-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
