Yeah--that makes sense. Fortunately I figured this out (by checking my backup on a different box) before I had a catastrophe.
So I switched my backup command to: rdiff-backup --exclude /home/eric/.evolution/cache/tmp --include /home/eric --include /srv/www --exclude '**' / /media/disk/Home-backup Since this was just adding 300-some KB to my backup (size of /srv/www) and I had done the /home/eric backup just a day or so back, I assumed the backup would go very quickly. In fact it ended up taking just over an hour. The only reason I can guess that it took so long was that with the new command there had to be a whole lot of re-indexing or such? Hopefully future incremental backups will go more quickly. Thanks. On Wed, 2009-10-21 at 18:30 -0400, R. David Murray wrote: > A quick look at the code reveals that --include-symbolic-links is just > the mirror option to --exclude-symbolic-links, and is just part of the > include/exclude file selection machinery. That is, you can choose to > never back up symlink files by using --exclude-symbolic-links. Why you > would ever want to use --include-symbolic-links is a good question, > since they will be picked up just like normal files in a regular include. > > There doesn't appear to be a mechanism to request that rdiff-backup > _follow_ symbolic links. I believe that to back up the linked directories > you will have to include them using their real path name. But the symlink > is still going to point to the original filesystem. In other words, > rdiff-backup is doing a literal copy of the symlink, so that if copied > back it will still be pointing to where it was originally pointing. > The symlink itself is the data being backed up when it is encountered. > > --David _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
