Re: using disk instead of tape
2006-09-05 10:11:05
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.
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.
Here for instance is an ls of last nights run here at the Heskett
Ranchette:
[root@coyote tesseract-1.0]# ls /amandatapes/Dailys/data
00000-Dailys-9
00000.Dailys-9
00001-coyote._var.2
00001.coyote._var.2
00002-coyote._usr_music.0
00002.coyote._usr_music.0
00003-coyote._usr_pix.0
00003.coyote._usr_pix.0
00004-coyote._usr_dlds-tgzs.0
00004.coyote._usr_dlds-tgzs.0
00005-gene._usr_src.1
00005.gene._usr_src.1
00006-gene._var.1
00006.gene._var.1
00007-gene._usr_local.1
00007.gene._usr_local.1
00008-gene._root.1
00008.gene._root.1
00009-gene._opt.1
00009.gene._opt.1
00010-gene._usr_bin.1
00010.gene._usr_bin.1
00011-gene._lib.1
00011.gene._lib.1
00012-gene._home.1
00012.gene._home.1
00013-gene._etc.1
00013.gene._etc.1
00014-gene._boot.1
00014.gene._boot.1
00015-gene._bin.1
00015.gene._bin.1
00016-gene._sbin.1
00016.gene._sbin.1
00017-coyote._opt.0
00017.coyote._opt.0
00018-coyote._usr_share.0
00018.coyote._usr_share.0
00019-coyote._root.1
00019.coyote._root.1
00020-coyote._usr_dlds-misc.0
00020.coyote._usr_dlds-misc.0
00021-coyote._usr_movies.0
00021.coyote._usr_movies.0
00022-coyote._home.0
00022.coyote._home.0
00023-coyote._GenesAmandaHelper-0.5.2
00023.coyote._GenesAmandaHelper-0.5.2
00024-coyote._usr_src.1
00024.coyote._usr_src.1
00025-coyote._dos.1
00025.coyote._dos.1
00026-coyote._usr_local.2
00026.coyote._usr_local.2
00027-coyote._boot.1
00027.coyote._boot.1
00028-coyote._usr_dlds-rpms.1
00028.coyote._usr_dlds-rpms.1
00029-coyote._usr_dlds.1
00029.coyote._usr_dlds.1
00030-coyote._usr_include.1
00030.coyote._usr_include.1
00031-coyote._usr_lib.1
00031.coyote._usr_lib.1
00032-coyote._lib.1
00032.coyote._lib.1
00033-coyote._dev.1
00033.coyote._dev.1
00034-coyote._tmp.1
00034.coyote._tmp.1
00035-coyote._etc.1
00035.coyote._etc.1
00036-coyote._usr_X11R6.1
00036.coyote._usr_X11R6.1
00037-coyote._usr_i386-glibc21-linux.1
00037.coyote._usr_i386-glibc21-linux.1
00038-coyote._usr_bin.1
00038.coyote._usr_bin.1
00039-coyote._usr_libexec.1
00039.coyote._usr_libexec.1
00040-coyote._usr_kerberos.1
00040.coyote._usr_kerberos.1
00041-coyote._usr_games.1
00041.coyote._usr_games.1
00042-coyote._sbin.1
00042.coyote._sbin.1
00043-coyote._bin.1
00043.coyote._bin.1
00044-coyote._usr_sbin.1
00044.coyote._usr_sbin.1
00045-coyote._usr_man.1
00045.coyote._usr_man.1
00046-TAPEEND
00046.TAPEEND
configuration.tar
indices.tar
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.
>Gr{oetje,eeting}s,
>
> Geert
>
>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert AT linux-m68k DOT org
>
>In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that. -- Linus Torvalds
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: using disk instead of tape, (continued)
- Re: using disk instead of tape, Ronan KERYELL
- Re: using disk instead of tape, Geert Uytterhoeven
- Re: using disk instead of tape, Phil Howard
- Re: using disk instead of tape, Ian Turner
- Re: using disk instead of tape, Ian Turner
- Re: using disk instead of tape, Phil Howard
- Re: using disk instead of tape, Geert Uytterhoeven
- Re: using disk instead of tape,
Gene Heskett <=
- Re: using disk instead of tape, Geert Uytterhoeven
- Re: using disk instead of tape, Gene Heskett
- Re: using disk instead of tape, Phil Howard
- Re: using disk instead of tape, Phil Howard
- Amanda vs. rsync vs. ... (was: Re: using disk instead of tape), Geert Uytterhoeven
- Re: Amanda vs. rsync vs. ... (was: Re: using disk instead of tape), Gene Heskett
- Re: Amanda vs. rsync vs. ... (was: Re: using disk instead of tape), Ian Turner
- Re: Amanda vs. rsync vs. ... (was: Re: using disk instead of tape), Geert Uytterhoeven
- Re: using disk instead of tape, Phil Howard
- Re: using disk instead of tape, Ian Turner
|
|
|