Amanda-Users

Re: using disk instead of tape

2006-09-05 17:50:04
Subject: Re: using disk instead of tape
From: Phil Howard <phil-amanda-users AT ipal DOT net>
To: amanda-users AT amanda DOT org
Date: Tue, 5 Sep 2006 16:43:31 -0500
On Tue, Sep 05, 2006 at 10:03:02AM -0400, Gene Heskett wrote:

| On Tuesday 05 September 2006 05:24, Geert Uytterhoeven wrote:
| >On Tue, 5 Sep 2006, Phil Howard wrote:
| >> On Sat, Sep 02, 2006 at 06:39:40PM -0400, Jon LaBadie wrote:
| >> | It certainly would destroy one of amanda's features,
| >> | the ability to easily recover backup data using
| >> | standard unix utilities without amanda software.
| >>
| >> How is that destroyed?
| >>
| >> Suppose you use tar format.  You can have tar read from tape directly,
| >> which is what I presume you mean for being able to recover outside of
| >> Amanda.  You can have tar read from disk partitions if the native
| >> partition scheme is used.
| >
| >At first I had the same reaction as you: it would work fine if you would
| > cycle your tapedev through the partitions.  However, then I realized a
| > tape can store multiple `files' sequentially, while a disk partition
| > can't (without hackerish that would annihiliate the easy recovery
| > again).
| >
| >So as long as you dump only one DLE, it would work fine. If you dump more
| > than one DLE, you need more logic.
| 
| I don't know how this conclusion was reached, but IMO its wrong.
| One of the beauties of amanda is that bare metal recoveries can be done 
| with nothing more than dd, tar(or dump if that what was used) and gzip.

And this could still be done with raw disk when using a compatible
(such as MSDOS) partitioning scheme, for the many OSes that support
MSDOS partitions (Linux, FreeBSD, NetBSD, OpenBSD, Solaris x86, at
least).


| Its far more trouble to locate a file you want on a sequential tape than it 
| is to locate it in a vtape.  The vtape itself is nothing more than a 
| subdir in a subdir in the filesystem of the hard drive.  Switching the 
| vtapes is as simple as replacing the link to the directory called data, 
| with a new link named data that points at the desired directory.

The raw disk would be like a raw tape, except that access to specific
"tape files" within would be much faster.  I don't claim that a raw
disk would have any of the benefits of backing up to a filesystem.


| for bare metal recovery, any of those files (in any order) can be accessed 
| with:
| #> tar xzf path-to-file-name-of-file
| 
| I've done it, it works, and its a whole lot EASIER than trying to locate a 
| file on a tape by scanning the tape until its finally found.  Hours 
| faster.  And note that dd wasn't used, its not required since the files 
| are random access, not sequential as on a tape.

FYI, at least on most systems I've worked with (all of those listed above)
even dd is not literally required.  Tar can read directly from tape or file.
It can even read directly from disk partitions (I've done so numerous times).

If you want all those benefits of restore, and don't mind having a disk
with a filesystem already on it, then why not use something like rsync
to make backups?  As long as you aren't working with over about a million
individual files, it works great.  It makes a replica of a filesystem or
multi-filesystem tree, and gives you direct access to every individual
file for restore purpose.  Use multiple disks to make multiple backups.
When backing up to a disk previously used, rsync avoids the writing work
for files not changed (according to matching meta data, though this can
be turned off).  And rsync works well over a network via ssh.

So I can't really understand your argument.  What you seem to specifically
want that dismisses raw disk might well be better served with rsync instead
of Amanda.  I might want Amanda, though, for huge volume and speed.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------