On 11/24/2012 09:32 AM, Les Mikesell wrote:
On Fri, Nov 23, 2012 at 11:57 AM, Gary Roach <gary719_list1@verizon.net> wrote:
  
PS: I don't want to tease you, but when deploying a backup system, the first
thing to check is if restore works as expected and has all the needed stuff.
And one should do that well before one needs it...

Yes. Anyone doing backup work should have your PS stamped on their forehead
or there butt which ever is closer to their brains. I think in my case its
probably the latter.
    
Or, spend a few minutes learning the documentation conventions when
starting with a new operating system.   Knowing things like what []'s
and ... mean when shown as command usage (and that the lack of []'s
means an argument is not optional there) can save years of
frustration.
  
I've been using Debian Linux for about 15 year. I spent 5 years as a programmer and about 40 year working with computers. I do no how to read documentation. I wrote enough of it in my work career. My degree in mathematics doesn't hurt either. Tone down your rhetoric a little.

  
I started thinking that all of the GUI information runs through Apache2 so I
turned logging up to debug and made another attempt at creating a tar file.
Lo and behold, I got the following error message in the Apache error log:

[Date stuff] [error] [client 127.0.0.1] Out of memory! referrer:
http//backupsystem/backuppc/index.cgi

I then opened a systems monitor program, re-ran things again and watched the
system ram max out and then the swap file start filling up. When the swap
file got to about 1.2GB the process quit. The swap file should be about 2 GB
so I am not sure what is going on here. If the problem is with my Apache
setup it might explain why no one else is having the problem. Any ideas?
    
That doesn't sound normal.  Are you using a ramdisk-based /tmp file
system - and maybe a configuration set up to cache everything?
Also, if your client is on the same host, where is it storing what it
receives?

  
The backup computer has 2 hard drives. One is used exclusively for backup files and nothing else. The other for BackupPC and the operating system.  When I do a GUI tar restore the the standard kde save file screen pops up and the files are copied to the OS hard drive from the backup hard drive. A restore.tar file is created in my /home/gary/Downloads directory. I do not appear to be using a ramdisk based system. But then with my lack of knowledge as to what is going on with this setup, any thing is possible. How would I tell for sure.
And does the same thing happen if you type the BackupPC_tarCreate
command line correctly?

  
Define correctly. The GUI "contents of backup" shows the "entry directory" as "/" (no parens) . The "contents of backup" shows:
        backuppc
        |_ etc
        |_home
        |_root
        |_var

Var has a list of excluded files. The rest are complete. Lets call the backed up computer  BC. The GUI shows the last full backup for BC as #169 with a #170 incrimental backup.  After su-ing to backuppc I get the following:

$ cd /usr/share/backuppc/bin
$ ./BackupPC_tarCreate -h BC -n 169 -s / >
/var/lib/backuppc/restore.tar
Use of qw(...) as parentheses is deprecated at
/usr/share/backuppc/lib/BackupPC/Storage/Text.pm line 302.
Use of qw(...) as parentheses is deprecated at
/usr/share/backuppc/lib/BackupPC/Lib.pm line 1413.
usage: ./BackupPC_tarCreate [options] files/directories...
  Required options:
     -h host         host from which the tar archive is created
     -n dumpNum      dump number from which the tar archive is created
                     A negative number means relative to the end (eg -1
                     means the most recent dump, -2 2nd most recent etc).
     -s shareName    share name from which the tar archive is created

  Other options:
     -t              print summary totals
     -r pathRemove   path prefix that will be replaced with pathAdd
     -p pathAdd      new path prefix
     -b BLOCKS       output write buffer size in 512-byte blocks (default 20;
same as tar)
     -w readBufSz    buffer size for reading files (default 1048576 = 1MB)
     -e charset      charset for encoding file names (default: value of
                     $Conf{ClientCharset} when backup was done)
     -l              just print a file listing; don't generate an archive
     -L              just print a detailed file listing; don't generate an
archive
$
The only thing fuzzy about this is what should go after -s . I've tried several different things with the same results. /var/lib/backuppc is owned by backuppc and is really the second hard drive containing the backup files. So in this case the restore.tar file is written to the backup disk. I also tried > /tar/restore.tar where /tar is a directory on the OS disk owned by backuppc. Same results except that the empty tar file was written to a different place. I've tried -s / / and also tried -s /etc. Nothing works.

Note: Debian Wheezy with BackupPC 3.2.1-3, 1GB ram, 2BG of swap memory and rsyncd for communications. All backups have worked fine for some months.

Any help will be sincerely appreciated.

Gary R.