Amanda-Users

Re: I don't think Amanda is going to work for my environment...

2004-03-18 16:16:01
Subject: Re: I don't think Amanda is going to work for my environment...
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: Michael Kahle <michael.kahle AT scc-wi DOT com>
Date: Thu, 18 Mar 2004 22:11:47 +0100
Michael Kahle wrote:
EXCLUDE doc, "The GNU version of tar, (gnutar or gtar), reads its
data at a file system, (or higher), level and does include the option
to exclude specific files and/or directories.  It should be mentioned
here that tar will change the access times no files.  Tar has the
ability to preserve the access times however, doing so effectively
disables incremental backups since resetting the access time alters
the inode change time, which in turn causes the file to look like it
needs to be archived again."  So, now this ads another problem to the
mix.  I cannot do incremental backups on files that I decide to
backup with gnutar, which I am using to solve my first problem.  This
is unacceptable.

The problem with access times is not as bad as it looks.
Some people like to preserve the access time of files, to have
a hint which files were used recently; or better, which were *not* used
recently (candidates to throw away or to archive).

While this is a valid issue for some of us, it is not a very reliable
indication. The access time of each file, garbage or not is easily
changed by a command like:
  grep -R 'From: paul.bijnens' .

But, the good news is that you *can* preserve the atime, without
modifying the ctime, if you believe this is very important.  See below.


If I am understanding this correctly, Amanda has no way to
incrementally backup a disk that also uses a exclude list to prevent
it from backing up certain files.  This seams to me to be an
important feature included in a backup package.

You don't understand this correctly.  The ability to do incremental
backups has nothing to do with exclude lists.  Backups with
excludes work fine, full and incremental, using gnutar.

Some versions of dump do alow to specify a subdirectory instead
of a complete filesystem. But in that case they cannot make
incremental backups of this.  This is only for dump, not for gnutar.


2. Not an intuitive way to think about backing things up.  This rant
is somewhat related to the above rant.  :)  The exclude files need to
be written on the client?  Again, from the EXCLUDE documentation, "An
...

The include/exclude directives can be on the server (in the
dumptype) or on the client, or a mix of both.  A disklist
entry could look like:

  my.server.com /my/dir {
        comp-user-tar
        exclude list append "/var/opt/amanda/exclude.gtar"
        exclude list append "./.exclude.gtar"
        exclude append "./scratch"
        exclude append "*.mp3"
        dumpcycle 7
        }

It has a dumptype adapted on the fly by the braces syntax.
The first exclude points to a general exclude file on the
client.  The second one is a file relative to the directory
"/my/dir", also on the client.  The last two are just strings,
sent to the client.  (and "comp-user-tar" could have some
exclude directives too).  The client merges all the files,
and directives in one file (because of the "append" keyword),
which you can find in the /tmp/amanda/*exclude* .


environments, it just doesn't make the grade.  Are there other backup
solutions out there that are free software that might better address my needs?

Not a user, but hear good comments about bacula:
  http://www.bacula.org/


Now, how to preserve the atime without changing the ctime, and, at
the same time avoiding a lot of other backup problems, like active
files etc?

Modern Linux and Solaris versions (and others probably too), have
volumemanagers or filesystems capable of doing snapshots.
Taking a snapshot takes usually less than a minute, during which
databases can be shut (or put in hot backup mode).  After the
snapshot is taken, the filesystem can be used as before. You can
then mount that snapshot somewhere in the filesystem in readonly mode
and make a backup of that snapshot.

Advantages:
- the downtime is really minimal.
- the atime is not changed.
- no more complaints about "file changed while reading...",
  and very consistent backup images.
- you can leave the snapshot mounted for the next day, letting
  users do their own restores from the "oops" mistakes, like "rm * .bak"
Disadvantages:
- you have to reserve a little bit diskspace (but much less than
  twice the total diskusage)
- slightly more complicated (my scripts are about 20 lines).

Amanda has a disklist syntax useful for it:

   my.server.com   /my/dir  /snap/my/dir  {
        comp-user-tar
        exclude append "core"
        }  1

this means that the logical directory is referred to as /my/dir,
but the backup is made from the device (directory) /snap/my/dir.

People who like to have a look at the scripts for Linux and Solaris
may contact me.

--
Paul Bijnens, Xplanation                            Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...    *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************

<Prev in Thread] Current Thread [Next in Thread>