On Thu, 25 Jun 2009 14:23:12 -0700 "Michael M. Moore" <mich...@writemoore.net> dijo:
> > However, I got an error on the .gvfs file: > > > > j...@devil7:~$ sudo rdiff-backup > > --include-globbing-filelist /home/jjj/rdiff_excludes.txt / > > /media/disk2/Full_system_backup > > ListError home/jjj/.gtkrc-1.2-gnome2/.gvfs [Errno 13] Permission > > denied: '/home/jjj/.gvfs' > If you don't want the error message, put it in your file list: > > - /home/jjj/.gtkrc-1.2-gnome2/.gvfs > - /home/jjj/.gvfs I have added the first one, but I got the error message about the second one also, even though it was in the list file. > > I also got pages and pages of additional errors. They were all of three > > types, examples here: > > > > UpdateError > > sys/devices/pci0000:00/0000:00:1d.7/usb2/usb_endpoint/usbdev2.1_ep00/bmAttributes > > Updated mirror temp > > file > > /media/disk2/Full_system_backup/sys/devices/pci0000:00/0000:00:1d.7/usb2/usb_endpoint/usbdev2.1_ep00/rdiff-backup.tmp.12219 > > does not match source > > Don't /sys/devices and other data under /sys change with each boot, or > each time a device is mounted? I thought one of the motivations for > using UUIDs in /etc/fstab instead of the more traditional /dev/hda1 (or > 2 or 3, etc) was that /dev entries are now dynamically assigned. Sysfs > is always going to be somewhat different between boots or mounts, as I > understand it anyway. I guess that begs the question, what is the value > in backing up /sys? I have also added /sys to the list file. We'll see. According to the rdiff-backup wiki, the UpdateError messages seem to be related to log files that are changing as the backup progresses. > > Can someone translate these to English for me? > > Not I ... hopefully somebody else can. I wonder if they resulted from > the fact that you were incrementing a backup that had previously been > created using pybackpack. I don't know what kind of issues that can > introduce -- it's possible that pybackpack adds some elements that > aren't present when you're using rdiff-backup by itself. I guess the > thing to do would be run the job again and see if you still get the same > errors. If you don't, then it was just temporary dissonance caused by > the differences in the methods you used. If you do, it might be safer > to delete the whole backup and do it again using rdiff-backup and only > rdiff-backup. Generally speaking, mixing and matching different > programs to do the same job is probably not a good idea. (I know > pybackpack is supposedly just a front-end for rdiff-backup, but > still ... it possibly introduces some subtle changes in the way > rdiff-backup works.) That sounds logical. I'm going to try another backup when I go to bed tonight. I will create a new folder for it so it will be a brand new backup created with rdiff-backup only. We'll see how it goes. > rdiff-backup does write a statistics file by default, though that can be > disabled with the --no-file-statistics option. If you want to see the > statistics at the conclusion of the job, use the --print-statistics > option. Otherwise (from the man page): > > STATISTICS > Every session rdiff-backup saves various statistics into two > files, the session statistics file at > > rdiff-backup-data/session_statistics.<time>.data > > and the directory statistics file at > > rdiff-backup-data/directory_statistics.<time>.data > > They are both text files and contain similar information: how > many files changed, how many were deleted, the total size of > increment files created, etc. However, the session statistics > file is intended to be very readable and only describes the > session as a whole. The directory statistics file is more > compact (and slightly less readable) but describes every > directory backed up. It also may be compressed to save space. > These files will be in your backup directory. There's also a log file > for the whole job. The log file and statistics files were not in the backup folder. Maybe that's another thing we can blame on pybackpack. > I'm not sure if rdiff-backup can display a progress bar. I'll try the --terminal-verbosity 9 option and see what happens. Ever since the backup this morning I'm getting kernel panics. I'm going to send this and then poke around some more. _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
