On Fri, 2006-01-27 at 10:45, Tony Nelson wrote: > >Yeah, you're right, I suppose the -u option of tar or the -f option of > >zip will probably work just fine. The reason I want to backup "changes > >only" is because I'm going be be doing nightly backups to a remote site > >and as the bandwidth is going to be limited. > > > >Additionally, as the file systems I'm going to be backing up to are SMB, > >I wanted the data to be compressed and archived into one file so if > >there are files with unsupported SMB filenames/lengths, they won't get > >stripped when put onto the SMB volume. I'm going to be doing this for > >some OS X servers as well. > > > >Does this make sense? You think this is an OK way to go about doing an > >"offsite" DR backup to a SMB volume? > > When you use tar, the destination filesystem won't get a chance to see or > muck with any of the attributes of the backed-up files. Probably the only > likely problem is with file-size limits. > > FWIW, tar can back up changes only, by keeping a list of files it has > backed up. See option --listed-incremental in "info tar", and the section > on Backups. I find info to be inscrutable, so "info tar", U, cursor down > to Backups, Enter. Yes, gnutar's --listed-incremental mode would work as long as you are sure you understand it and the way you have to restore the full first, then all subsequent incrementals where you specified the same filename. However it won't be as efficient about handling modifed or growing files. Each tar run will transfer a copy of the whole thing where rsync would find and send the changes. I'd recommend adding a drive to the box where you run the rsync to avoid the smb limitations, but depending on the circumstances you might try something more imaginative - like running a VMware virtual machine (runtime is free now) on the box where you planned to export the smb share so you could rsync to it's virtual drive contained in a file. -- Les Mikesell lesmikesell@xxxxxxxxx
