VFS Device: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
(rearrange, don't call it "file driver" anymore)
(replace with redirect to manpage)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<div style="float: right;">__TOC__</div>
See {{man|7|amanda-devices}}.
=Introduction=
 
Since release 2.4.3, Amanda supports the usage of a VFS Device, with prefix "file:".
 
As the name suggests, this driver uses files on disk as virtual tapes.  Amanda can write to and read from virtual tapes, just like real tapes.  A bunch of virtual tapes can even be manipulated with a changer.
 
Possible Uses
* Disk-based installations: You can use the file driver to backup onto a set of virtual tapes hosted on a bunch of hard-disks or a RAID-system. Combined with another Amanda configuration that dumps the virtual tapes to real tapes, you can provide reliable backup with faster tapeless recovery. This is called "disk-to-disk-to-tape" backup by some people today.
 
* Inexpensive installations: Without buying a tape drive you can enjoy the benefits of Amanda and backup to a bunch of harddisks. You can create CD/DVD-sized backups which you can burn onto optical disks later. Or you can backup to external disks connected with Firewire or USB.
 
* Test installations: You can easily explore the rich features of Amanda on systems without tape drives.  Virtual tapes are usually also much faster than many real tape drives. For a quick start, have a look at: [[Test environment with virtual tapes]].
 
Please be sure to understand the differences between holding disks and virtual tapes. The two serve different purposes; holding disks allow for parallelism of multiple disklist entries (DLE's) being backed up while virtual tapes are a replacement for physical tapes.
 
The virtual tapes are also called "vtapes" in this document.
 
= Using Virtual Tapes =
A virtual tape is implemented as a directory with a subdirectory named "data" in it.
 
# chown amanda:disk /amandatapes
# chmod 750 /amandatapes                      # backups contain secret files!
# su - amanda
$ mkdir -p /amandatapes/test/tape1/data
 
This tape can be manipulated by the [[ammt]] command, a replacement for the system command "mt". The ammt command understands the different output drivers from Amanda:
 
$ ammt -f file:/amandatapes/test/tape1 status
$ ammt -f file:/amandatapes/test/tape1 rewind
 
Vtapes are always non-rewinding.  Just like Amanda needs them.  That's why you always need to rewind it when you want to start reading a vtape from the beginning.
 
Basic writing to a vtape can be done with [[amdd]], a replacement for the system command "dd".  Virtual tapes have no real builtin capacity; the upper limit is "diskspace, the final frontier". However Amanda does obey the size you specify in tapetype definition of a vtape in amanda.conf. The amdd command also can specify an upperlimit on the virtual tapesize with the '''-l''' option:
 
$ amdd -l 200k if=/dev/urandom of=file:/amandatapes/test/tape1 bs=32k
amdd: write error: No space left on device
8+0 in
6+1 out
 
The above command writes 200 Kbytes of garbage (6 full blocks of 32k + 1 partial block) on the vtape before it bumps into the end of the virtual tape.
 
When there is no "data" subdirectory in a vtape, the vtape is "offline".  You could burn the contents of the data directory to a CD-R, and store that away.  When you want to read it, just mount is as a "data" directory, or even simpler, create a symlink "data" pointing to the mounted cdrom.
 
$ rm -r /amandatapes/test/tape1/data
$ ammt -f file:/amandatapes/test/tape1 status
file:/amandatapes/tape1: status: OFFLINE
$ ln -s /media/cdrom /amandatapes/test/tape1/data
$ ammt -f file:/amandatapes/test/tape1 status
file:/amandatapes/test/tape1: status: ONLINE
 
Amanda cannot backup a to CD-R, but can use it as a read protected vtape; making a backup to a vtape, and and later burning the contents of the '''data''' directory to a CD or DVD is the normal way.
 
= See Also =
* [[How To:Set Up Virtual Tapes]]
 
= Credit =
Based on text by: Stefan G. Weichinger, November - December, 2003 ; minor updates in April, 2005.

Latest revision as of 21:11, 5 August 2008