README for adding PC hosts to the Amanda backup system.

Installation

Amanda is able to back up Microsoft Windows shared disks by using
Samba, a package that implements a SMB client and server for Unix.
Releases from 1.9.18p5 up to 1.9.18p10 would log information in the
tar files it produces, making them unusable (both the tar files and
the releases of Samba :-)!  If you really must use a release prior to
Samba 2.0.0, a patch that fixes the problem is available in the Amanda
Patches Page too.

Amanda no longer supports Samba releases prior to 1.9.18.  If you're
using Samba from 1.9.18 up to 1.9.18p3, make sure you don't set a low
logging/debugging level in smb.conf.  This flag may prevent that
estimate sizes are printed correctly.  Amanda will report an estimate
failure in this case.

This problem may also occur if you have large (>2GB) filesystems to
back up with Samba prior to 2.0.4.  In this case, apply
samba-largefs.patch.

After building and installing samba with the selected patches, Amanda
must be configured with smbclient support - when you run configure,
you may add the following argument:

 --with-smbclient=/full/path/to/smbclient

By default, amanda will try to find smbclient in the PATH.  If it is
not found, or it appears not to be smbclient, Samba support won't be
enabled.

Setup

Once Amanda is installed, the only difference is in how the backup
disks are specified.  For each PC host disk, and entry is placed in the
disklist not for that host, but for the 'samba server' host, where the
patched samba suite is installed.  Instead of a path or a disk
specified in the space provided in the disklist for this purpose, a
sharename is listed.

Additionally, a file must be created called /etc/amandapass, which
includes a sharename to password mapping.  Each line of input
lists the sharename in 'Amanda format' (it is case sensitive so
make it identical to the sharename listed in the disklist) followed
by whitespace and then the password, which must not contain spaces.
This file must owned by the amanda user, and without world-read
privileges, or amcheck will complain.

The share must be given full access (read/write) to the disk -
otherwise incremental backups will not work and it will always backup
most of the disk (Archive bits never being reset).

e.g.

Amanda client software, and the patched samba is installed onto a host
'pcserver'.  A share to be backed up is called 'backupc' on host
'thepc'.  The share will be accessed with the user 'bozo' and
password 'f00bar'.

The entry in the disklist file is:

pcserver	//thepc/backupc		nocomp-user-gnutar

^ samba installed unix host
                 ^ pc host and sharename
					^ dumptype must include the tar option

And in /etc/amandapass on the machine 'pcserver', this line must be
present :
//thepc/backupc bozo%f00bar

If smbclient would require a workgroup specification (-W), you may add
it as a third argument in /etc/amandapass line:
//thepc/backupc bozo%f00bar NTGROUP

This way, smbclient will be invoked with -W NTGROUP


An example dumptype (from amanda.conf) could be:

define dumptype nocomp-user-gnutar {
    program "GNUTAR"
    comment "user partitions dumped with tar and no compression"
    options no-compress
    priority medium
}

Essentially the disklist entry is a 'pseudo-disk' which contains all the
relevant information needed by the smbclient program to backup the disk,
but in an Amanda compatible way.  The full sharename shouldn't be greater
than 79 characters.  And the password should not include any whitespace.

For NT systems, or where the shares are specified with a username, the
username it connects with is 'backup'.  See bugs for some notes on
this.

amcheck does a quick check to see if smbclient exits and also tries to
connect to any appropriate hosts.  It also checks for the existence of
/etc/amandapass, and that the permissions are set appropriately.

Bugs

Samba will not back up open files (such as PAGEFILE.SYS and registry
files) nor Access Control List data.  Furthermore, at restore time,
smbclient is unable to overwrite read-only files.  Hence, Amanda+Samba
is not a perfect solution for backing up (restoring, actually) system
disks.

Samba does not use Windows' Backup API, so configuring the Amanda
backup user as a member of group backup, in the Windows host, is
useless.  You will probably have to configure it as an Administrator,
and make sure that it can read and change permission of *all* files in
the share.

It seems impossible to detect when a per-user based login fails - e.g.
the username doesn't exist on an NT workstation.  It connects but you
can't see any files (e.g. backups backup nothing).  The selfcheck code
isn't particularly robust in this area either, so you can get no
warnings when a disk isn't being backed up.  Just check to see that
level 0 dumps are bigger than 64K - otherwise it means the backup was
empty.  (i have code in sendsize to detect this situation, but I don't
know how to flag it, without aborting every disk (or 'pseudo disk') on
that host).

The estimate and totals are probably a bit out, since tar pads to the
nearest 512 bytes after each file (i think).  Not sure how much of a
problem this is.

If you compile with smbclient support, gnutar support is automatically
added too.  If you aren't using the gnutar part, you may get warnings
about the availability of /usr/local/bin/gtar (or whatever it was
compiled with) - these can safely be ignored, unless you enable index
generation for those filesystems.

Original text by:
Michael Zucchi
School of Computer and Information Science
University of South Australia
M.Zucchi@CIS.UniSA.Edu.Au