🚀 go-pugleaf

Mark Brun <m.brun@tic.ch> wrote:
> Dann wie weiter ? Wie bekomme ich ein Device f�r dieses Band ?

There are many possibilities. The one I use are:

   - QIC-250 (SCSI big and old, slow, and not a lot: 250 MB)
     However, I have a stock of them (a pile), they are very
     reliable. I use that for incremental backups mostly.

   - Exabyte 8mm 8200: quite reliable, but slow. I have a few
     cartridges. 2.5 GB. SCSI.

   - DAT: a lot of different options. At this time I have an old
     HP DAT (upto 90m tapes, around 2 GB/tape).

Also, I happen to work for a company manufacturing autochangers,
and all of our products are supported on Linux. I don't want
to do too much advertising, but this week end the Linux test
bench at work is testing the latest version: a SDT-10'000 (SONY)
with a 8-slot autochanger.  This unit is supposed to offer
a minimum of 20 GB / cartridge (and thus that unit would offer
160 GB if you don't use a slot for a cleaning tape -- you should),
more with compression. More details at http://www.dilog.ch/

All values without software or hardware compression.

> Welche Befehle oder packages verwendet man am Besten ?

Now, your question:

1. method 1 (the best if you know what you are doing, and you should if
             you want reliable backups in general ...)

   do a few simple scripts using tar or cpio, find, and mt

   init:
   mt -f /dev/nst0 rewind
   mt -f /dev/nst0 setblk 0

   with cpio:
   cd /
   for i in . usr users other-mount-point
   do
      find $i -mount -depth -print | cpio -Hcrc --io-size=32768 -O /dev/nst0
   done

   with tar
   cd /
   tar cvf /dev/nst0 --exclude='proc/*' .

   In the cpio case above I create multiple files, one per filesystem,
   when you want to verify or restore them, you either read sequentially
   (and boundary is seen by an empty read()), or you go directly to
   the right file:
      mt -f /dev/nst0 rewind; mt -f /dev/nst0 fsf 1 # forward skip one file

   To list, use:
      tar tvf
      cpio -ivt

   With tar you can also verify (--compare option, see info manual).

   Some people prefer to use dump/restore. I strongly advise against it.
   First, it's non-portable (you can't read back a Linux ext2dump
   on Solaris, for example). Second, there have been bugs in the past
   regarding working on a mounted filesystem. Third, countrary to tar/cpio,
   this uses the raw device, and thus each time you upgrade your kernel
   you should ensure you have the right ext2dump. Also, you cannot backup
   MS-* filesystems.

2. method 2 (if you like graphical interfaces)

   option 1:
      - use the KDE kdat program
   option 2:
      - use some commercial package, such as BRU2000 or Arkeia,
        the latter can also backup networks, many computers, including
        MS-* stuff. Arkeia supports autochangers.

3. method 3 (backup a network of UNIX workstation, possibly to a central
             autochanger Linux server)

   For example, to backup our engineering network (a few Linux workstations,
   some with dual-boot and thus MS-* fses are mounted for backup,
   a Solaris server, a Linux server, and a MS-*'NT firmware server), I
   use the freely available Amanda software. You simply tell Amanda how
   much tapes you want to cycle, and how often you want a complete
   a full backup (non incremental). Amanda automatically decides what
   it has to do based on parallel estimates computed by clients (such
   as: level 0 would be 1 GB, level 1 (== incremental since last level 0)
   would be 200 MB, level 2 (== incremental since last level 1) would
   be 10 MB), disk capacity, tape capacity, and incremental/dump progression
   rules. Amanda can use standard tar (or dump, if you want it). Backups
   are done in parallel, upto rules of bandwidth usage, to a holding disk,
   so to ensure very efficient tape usage. For example, while one backup
   is saved to tape at maximum speed from hold disk, another computer writes
   into the holding disk. Backup of MS-* systems is done by smbclient,
   so doesn't backup registry and other things like ACLs. However, for
   plain data backup (especially if you want to migrate soon to UNIX),
   it's perfect, since it's also saved as tar format.

   Restores can be done by name, date, tapes. Also, for disaster recovery,
   you don't need to re-install Amanda, a boot disk with the appropriate
   SCSI or other tape drivers and ``tar'' is sufficient. tapes are labelled
   clearly, and all files are also labelled, as text, easily extractible.
   Amanda maintains a catalog of all the files backuped for very efficient
   retrieving (but it's not necessary for disaster recovery). 

   Sumamry for Amanda:
      - maybe a little difficult to setup completely and safely
      - no graphical interface (which is an advantage some times)
      + can use standard UNIX utilities instead of reinventing the
        backup tools or use unreliable/non portable dump/restore
      + can backup all UNIX clients
      + can backup MS-* clients's data
      - cannot backup MS-* registry or open files, nor ACLs.
      + can backup more than one client in parallel
      - cannot write files spanning tapes, so big fs might need to be
        splitted manually
      - backups not fitting on the hold disk are piped to tape
      + supports autochangers
      + supports Kerberos security, or ssh, or rlogin
      - some US export issues with Kerberos
      + automatically does tape recyling, with label checks
      + automatically decides what needs to be backuped, when,
        and schedules the backup levels
      - uses at minimum one tape a day (cannot append to tapes),
        so this scheme works best if daily backup size == approximately
        tape size. Using a tape/day is explained by the developpers:
        so important backups are not lost. Alternatively, you can
        configure Amanda to dump to the holding disk, and only dump
        to tape when you have enough (experimental!).
     
Ok,  that's already a lot for you to read :)