On Sun, Feb 23, 2003 at 01:38:45PM +1100, Rachel Polanskis wrote:
> hi,
>
> I am running Amanda-2.4.2 on Solaris 8. I've been doing this for some time
> and all my remote clients work fine. My local backup server streams
> everything
> to a DDS2 drive and typically I have had no problem.
>
> Recently the size of the /opt filesystem on my server has grown to well over
> 4Gb. Since then, dumps of /opt have failed and I have no current backup
> of the filesystem.
>
> I have done lots of research and decided to use GNU tar to back up the
> filesystem
> instead, just picking the critical directories that need dumping.
>
> This is not working at all, however. I am now seriously desparate to
> get this filesystem backed up. I am protected against critical disk
> failure, thanks to the mirrored volume, but not against user errors such as
> deleted files. I have upgrded tar to 1.3.19 and just about to move to 1.3.25
> but nothing happens. Amcheck tells me everything is OK, but the tar portion
> of the backups never happens, only the ufsdumps. Also, my amreport email
> is always empty, as it seems to dump core. I have to use manual
> tools to check the reporting.
>
Was gnutar available when you configured and compiled amanda?
What I'm getting at is whether amanda is even finding the gnutar you have
installed now or whether it maybe is using the default /bin/tar.
Check your /tmp/amanda/runtar* files to see what it is trying to execute.
Perhaps also the corresponding sendbackup files for any errors.
If amanda has the correct path to gnutar, is <install_dir>/libexec/runtar
setuid'ed root?
BTW, once you get it set up (I know it works, I use it on Solaris), you
don't have to backup only "important" subdirs. In addition to your DLE's
like /opt/sub1, /opt/sub2, ... also list a DLE of /opt. BUT, have that
one use a unique dumptype, say "user-tar-opt" that is only two lines long.
The first includes "user-tar" and the second specifies an exclude file
that excludes all the separately backed-up subdirs. This DLE is a catchall
for everything not specifically backed up with a separate DLE.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
