Re: amfetchdump inventory mode
On Thursday 27 September 2007 11:57:53 Dustin J. Mitchell wrote: > To summarize the levels of functionality for restore: > OS, Amanda, Config, Logs, Indices: use amrecover > OS, Amanda, Config, Logs: use amfetchdump > OS, Amanda: use amrestore[1], or use inventory to recover the logs > and then use amfetchdump > OS: use native tools Yes, although I'd add to that list that you can (in theory) restore and reassemble split files without logs but with a working config using amfetchdump. It should even be able to operate a changer. > P.S. I think it will make more sense to move the inventory mode to > amrestore, making that the generic restore-without-config-or-indices > tool. It doesn't really fit well with the operation of amfetchdump, > IMHO. Opinions welcome. IMNSHO, amfetchdump -i is not all that useful to begin with, because you still can't use amrecover to browse the logfiles without also having complete indexes. I think it would make more sense to combine the upcoming "reindex" functionality with any "relog" functionality, whether via options on an existing tool or via an entirely new tool. --Ian -- Wiki for Amanda documentation: http://wiki.zmanda.com/
Re: amfetchdump inventory mode
* Dustin J. Mitchell <[EMAIL PROTECTED]> [20070927 11:59]: > On 9/27/07, Jean-Francois Malouin > <[EMAIL PROTECTED]> wrote: > > Yes, you're right that it is manually feasable. However conceptually > > simple the task is, I feel that potential mistakes are bound to > > happen, particularly when doing a restore under pressure! Remember, > > you have the mob^H^H^Husers on your back, yelling bad words at you :) > > > > I'll see if I can write a dirty little script that could somehow > > automate the procedure... > > Just to be clear, while native-tools restores are important, and not a > feature we're considering dropping, they should be *very* rare. right, but just because it is a very remote possibility doesn't mean one must not be prepared for it! It's all about contingency plans... Like monitoring asteroids in the Earth vicinity...no one really cares until the Big Hit :) > It's the purpose of the inventory mode, as well as amrestore, to deal > with the situation where a fresh install of Amanda, without much > configuration (just a tapedev), must perform a restore. > > To summarize the levels of functionality for restore: > OS, Amanda, Config, Logs, Indices: use amrecover > OS, Amanda, Config, Logs: use amfetchdump > OS, Amanda: use amrestore[1], or use inventory to recover the logs > and then use amfetchdump > OS: use native tools > > Unless you're locked in a bunker without access to Amanda binaries, > installing Amanda on a fresh box should probably be the first step of > your bare-metal restore process. That said, you can be confident > that, given a swiss army knife, some duct tape, and a basic UNIX > system, you *can* get at your data. Funny, our machine room is actually called 'The Bunker'! Concrete all over the walls, ceiling and floor... Not ideal but we had no choice. And one 1.5T and 3T MRI scanners located directly underneath it! > > Dustin > > P.S. I think it will make more sense to move the inventory mode to > amrestore, making that the generic restore-without-config-or-indices > tool. It doesn't really fit well with the operation of amfetchdump, > IMHO. Opinions welcome. As you clearly explained above you're right that the inventory functionality should then be at the amrestore level... > > [1] At the moment, amrestore doesn't support splitfile reassembly, > although it's easy enough to do manually with 'cat'. We'll be adding > that capability to amrestore soon. > > -- > Storage Software Engineer > http://www.zmanda.com regards, jf -- <° ><
Re: amfetchdump inventory mode
On 9/27/07, Jean-Francois Malouin <[EMAIL PROTECTED]> wrote: > Yes, you're right that it is manually feasable. However conceptually > simple the task is, I feel that potential mistakes are bound to > happen, particularly when doing a restore under pressure! Remember, > you have the mob^H^H^Husers on your back, yelling bad words at you :) > > I'll see if I can write a dirty little script that could somehow > automate the procedure... Just to be clear, while native-tools restores are important, and not a feature we're considering dropping, they should be *very* rare. It's the purpose of the inventory mode, as well as amrestore, to deal with the situation where a fresh install of Amanda, without much configuration (just a tapedev), must perform a restore. To summarize the levels of functionality for restore: OS, Amanda, Config, Logs, Indices: use amrecover OS, Amanda, Config, Logs: use amfetchdump OS, Amanda: use amrestore[1], or use inventory to recover the logs and then use amfetchdump OS: use native tools Unless you're locked in a bunker without access to Amanda binaries, installing Amanda on a fresh box should probably be the first step of your bare-metal restore process. That said, you can be confident that, given a swiss army knife, some duct tape, and a basic UNIX system, you *can* get at your data. Dustin P.S. I think it will make more sense to move the inventory mode to amrestore, making that the generic restore-without-config-or-indices tool. It doesn't really fit well with the operation of amfetchdump, IMHO. Opinions welcome. [1] At the moment, amrestore doesn't support splitfile reassembly, although it's easy enough to do manually with 'cat'. We'll be adding that capability to amrestore soon. -- Storage Software Engineer http://www.zmanda.com
Re: amfetchdump inventory mode
Chris, * Chris Hoogendyk <[EMAIL PROTECTED]> [20070926 17:20]: > > > Jean-Francois Malouin wrote: > >* Ian Turner <[EMAIL PROTECTED]> [20070926 15:37]: > > > >>On Wednesday 26 September 2007 14:57:58 Jean-Francois Malouin wrote: > >> > >>>I'm trying to understand how 'amfetchdump -i' works (amanda-2.5.2p1): > >>> > >>At the moment, not all that well. :-( In theory, amfetchdump can be used > >>to recreate the Amanda logfile used to track which dumps were stored > >>where. So if your backup server bites the dust (and wasn't itself backed > >>up), you can use amfetchdump -i to restore the logs. After that, you will > >>be able to use amfetchdump to operate the changer and restore specific > >>dumps. Note, however, that amfetchdump -i will not restore the indices, > >>so you'd still be unable to use amrecover in that case. > >> > >>I have it on my plate to fix amfetchdump -i, but before I do so, maybe I > >>should ask for a show of hands: How needed is this feature, anyway? > >> > > > >You mean the "do this to get what's needed for amfetchdump to work"? > > > >In my book it's absolutely essential! I would (I am now!) be very > >nervous to rely on a restore utility that would not work when > >things get real'bad. > > > >One of the most important feature of amanda was (it still is but read > >on) the possibility of doing a bare-metal restore with just a few > >utilities. I say was because in my case the ever increasing amount of > >data, the size of the DLEs and the number of chunks needed in order to > >fit in my tapes (LTO-1 and LTO-3) was getting out of hand --too much > >likely to 'forget' some data while including/excluding dirs in a DLE-- > >so I had to use the tape spanning feature. I get a much better tape > >usage but now I can't do bare-metal restores in case something real > >bad happens. I understand that I can't have both the cake AND the > >cherry but I would be hard pressed to justify using amanda to our > >computer people at my site when such an important feature is missing. > > > >But what is exactly needed by amfetchdump? > >The amdump and log files in the logdir? > > > >Sorry for the long tirade! > >Thanks, jf > > > Just as a point of reference, I have a daily cron job that follows > amdump. It watches Amanda to see that it has completed. Then it backs up > the entire /usr/local/etc/amanda directory to another drive on the same > system, then tars and gzips it and scp's it to an archive directory on a > different server. So, every time I run amdump, I follow it with a backup > of a backup of the amanda directories and everything they contain -- > configs, indexes, etc. If the drive fails, I have it on another drive. > If the system fails, I have it on another system. And those end up on > tape the next day. I do something similar: I have amanda running a ssh agent and when amdump finishes I rsync over ssh the amanda configs to several remote hosts. Just to be paranoid, I also cross-backup all the different configs among themselves over the different servers (3 of them). regards, jf > > I also have on my intended projects for this fall a Solaris-9/Amanda > bootable disaster recovery CD. I have it all sketched out, just the down > and dirty work to do, and then document my implementation notes in > enough detail that others can do it. My intention is to have a reserved > IP for disaster.my.department.edu, so I don't have to mess with any > install miniboot, reboot, configure the interface, etc. It will just > boot and allow me to run amrecover with a connection to the Amanda > server. I probably shouldn't be touting my chickens before my eggs are > hatched. But, that's the plan. > > For the server, it gets a little messier. But, I have several alternate > contingency plans, including just a silly old DAT of the Amanda server. > Recover that (so I have the drivers for the AIT5 Tape Library, among > other things), pull the latest amanda directory from the other server > where it was archived after the last successful backup, and I'm back in > business. > > > > --- > > Chris Hoogendyk > > - > O__ Systems Administrator > c/ /'_ --- Biology & Geology Departments > (*) \(*) -- 140 Morrill Science Center > ~~ - University of Massachusetts, Amherst > > <[EMAIL PROTECTED]> > > --- > > Erdös 4 > -- <° ><
Re: amfetchdump inventory mode
Hi Jon,
* Jon LaBadie <[EMAIL PROTECTED]> [20070926 17:49]:
> On Wed, Sep 26, 2007 at 04:26:50PM -0400, Jean-Francois Malouin wrote:
> >
> > One of the most important feature of amanda was (it still is but read
> > on) the possibility of doing a bare-metal restore with just a few
> > utilities. I say was because in my case the ever increasing amount of
> > data, the size of the DLEs and the number of chunks needed in order to
> > fit in my tapes (LTO-1 and LTO-3) was getting out of hand --too much
> > likely to 'forget' some data while including/excluding dirs in a DLE--
> > so I had to use the tape spanning feature. I get a much better tape
> > usage but now I can't do bare-metal restores in case something real
> > bad happens. I understand that I can't have both the cake AND the
> > cherry but I would be hard pressed to justify using amanda to our
> > computer people at my site when such an important feature is missing.
> >
>
> Jean-Francois,
>
> I think you lose less than you realize. I've not tested a bare-metal
> restore with my spanned dumps, but here is how I view the procedural
> difference from a non-spanned dump.
>
> For non-spanned:
>
> 1. you need to locate the specific tape file where the DLE begins.
> 2. you need to use mt to position your tape at the beginning of the file
> 3. you need to use dd to strip off the first 32KB of the tape file.
> 4. you need to feed the rest of the file to your restore command(s),
>eg. unzip, tar, ...
>
> For spanned:
>
> 1. the same except you also need to determine the number of chunks and
>whether it spreads to multiple tapes
> 2. the same
> 3. a modification
> 4. the same
>
> Recognize that the spanned pieces are all one after the other on the
> tape, and if crossing to another tape, at the beginning of that tape.
> But, if it crosses to another tape, the last chunk on the tape is
> not valid.
>
> So step 3 becomes not one "dd bs=32k skip=1 ..." but a loop through
> the chunks doing the same dd command on each chunk. In a scenario
> where you knew the dump was in 5 chunks, step 3, piped into step 4
> could be simply:
>
> for i in 1 2 3 4 5
> do
> dd bs=32k skip=1 if={your tape dev}
> done | {step 4 commands}
>
> Obviously it would be more complex if the DLE were split over
> multiple tapes, but then something like this is possible:
>
> (
> FOR LOOP FROM ABOVE
> tape change commands
> tape position commands (to skip over amanda tape header to first file)
> ANOTHER FOR LOOP
> ) | {step 4 commands}
>
> And I've ignored the bad last chunk.
>
> If sufficient disk space were available, you could just save
> each chunk with a sequential number. Then cat the chunks
> piping them into the step 4 commands.
>
> Amfetchdump tries to automate this.
> And if I understand the -i option, assists in locating the chunks.
> But it still can all be done manually.
>
> What you lose by spanning is the simplicity of having the entire
> dump in a single tape file. But the manual recovery procedure
> is still basically the same.
Yes, you're right that it is manually feasable. However conceptually
simple the task is, I feel that potential mistakes are bound to
happen, particularly when doing a restore under pressure! Remember,
you have the mob^H^H^Husers on your back, yelling bad words at you :)
I'll see if I can write a dirty little script that could somehow
automate the procedure...
Thank you for taking the time to comment!
jf
>
> --
> Jon H. LaBadie [EMAIL PROTECTED]
> JG Computing
> 4455 Province Line Road(609) 252-0159
> Princeton, NJ 08540-4322 (609) 683-7220 (fax)
--
<° ><
Re: amfetchdump inventory mode
On Wed, Sep 26, 2007 at 04:26:50PM -0400, Jean-Francois Malouin wrote:
>
> One of the most important feature of amanda was (it still is but read
> on) the possibility of doing a bare-metal restore with just a few
> utilities. I say was because in my case the ever increasing amount of
> data, the size of the DLEs and the number of chunks needed in order to
> fit in my tapes (LTO-1 and LTO-3) was getting out of hand --too much
> likely to 'forget' some data while including/excluding dirs in a DLE--
> so I had to use the tape spanning feature. I get a much better tape
> usage but now I can't do bare-metal restores in case something real
> bad happens. I understand that I can't have both the cake AND the
> cherry but I would be hard pressed to justify using amanda to our
> computer people at my site when such an important feature is missing.
>
Jean-Francois,
I think you lose less than you realize. I've not tested a bare-metal
restore with my spanned dumps, but here is how I view the procedural
difference from a non-spanned dump.
For non-spanned:
1. you need to locate the specific tape file where the DLE begins.
2. you need to use mt to position your tape at the beginning of the file
3. you need to use dd to strip off the first 32KB of the tape file.
4. you need to feed the rest of the file to your restore command(s),
eg. unzip, tar, ...
For spanned:
1. the same except you also need to determine the number of chunks and
whether it spreads to multiple tapes
2. the same
3. a modification
4. the same
Recognize that the spanned pieces are all one after the other on the
tape, and if crossing to another tape, at the beginning of that tape.
But, if it crosses to another tape, the last chunk on the tape is
not valid.
So step 3 becomes not one "dd bs=32k skip=1 ..." but a loop through
the chunks doing the same dd command on each chunk. In a scenario
where you knew the dump was in 5 chunks, step 3, piped into step 4
could be simply:
for i in 1 2 3 4 5
do
dd bs=32k skip=1 if={your tape dev}
done | {step 4 commands}
Obviously it would be more complex if the DLE were split over
multiple tapes, but then something like this is possible:
(
FOR LOOP FROM ABOVE
tape change commands
tape position commands (to skip over amanda tape header to first file)
ANOTHER FOR LOOP
) | {step 4 commands}
And I've ignored the bad last chunk.
If sufficient disk space were available, you could just save
each chunk with a sequential number. Then cat the chunks
piping them into the step 4 commands.
Amfetchdump tries to automate this.
And if I understand the -i option, assists in locating the chunks.
But it still can all be done manually.
What you lose by spanning is the simplicity of having the entire
dump in a single tape file. But the manual recovery procedure
is still basically the same.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amfetchdump inventory mode
Jean-Francois Malouin wrote: * Ian Turner <[EMAIL PROTECTED]> [20070926 15:37]: On Wednesday 26 September 2007 14:57:58 Jean-Francois Malouin wrote: I'm trying to understand how 'amfetchdump -i' works (amanda-2.5.2p1): At the moment, not all that well. :-( In theory, amfetchdump can be used to recreate the Amanda logfile used to track which dumps were stored where. So if your backup server bites the dust (and wasn't itself backed up), you can use amfetchdump -i to restore the logs. After that, you will be able to use amfetchdump to operate the changer and restore specific dumps. Note, however, that amfetchdump -i will not restore the indices, so you'd still be unable to use amrecover in that case. I have it on my plate to fix amfetchdump -i, but before I do so, maybe I should ask for a show of hands: How needed is this feature, anyway? You mean the "do this to get what's needed for amfetchdump to work"? In my book it's absolutely essential! I would (I am now!) be very nervous to rely on a restore utility that would not work when things get real'bad. One of the most important feature of amanda was (it still is but read on) the possibility of doing a bare-metal restore with just a few utilities. I say was because in my case the ever increasing amount of data, the size of the DLEs and the number of chunks needed in order to fit in my tapes (LTO-1 and LTO-3) was getting out of hand --too much likely to 'forget' some data while including/excluding dirs in a DLE-- so I had to use the tape spanning feature. I get a much better tape usage but now I can't do bare-metal restores in case something real bad happens. I understand that I can't have both the cake AND the cherry but I would be hard pressed to justify using amanda to our computer people at my site when such an important feature is missing. But what is exactly needed by amfetchdump? The amdump and log files in the logdir? Sorry for the long tirade! Thanks, jf Just as a point of reference, I have a daily cron job that follows amdump. It watches Amanda to see that it has completed. Then it backs up the entire /usr/local/etc/amanda directory to another drive on the same system, then tars and gzips it and scp's it to an archive directory on a different server. So, every time I run amdump, I follow it with a backup of a backup of the amanda directories and everything they contain -- configs, indexes, etc. If the drive fails, I have it on another drive. If the system fails, I have it on another system. And those end up on tape the next day. I also have on my intended projects for this fall a Solaris-9/Amanda bootable disaster recovery CD. I have it all sketched out, just the down and dirty work to do, and then document my implementation notes in enough detail that others can do it. My intention is to have a reserved IP for disaster.my.department.edu, so I don't have to mess with any install miniboot, reboot, configure the interface, etc. It will just boot and allow me to run amrecover with a connection to the Amanda server. I probably shouldn't be touting my chickens before my eggs are hatched. But, that's the plan. For the server, it gets a little messier. But, I have several alternate contingency plans, including just a silly old DAT of the Amanda server. Recover that (so I have the drivers for the AIT5 Tape Library, among other things), pull the latest amanda directory from the other server where it was archived after the last successful backup, and I'm back in business. --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst <[EMAIL PROTECTED]> --- Erdös 4
Re: amfetchdump inventory mode
* Ian Turner <[EMAIL PROTECTED]> [20070926 15:37]: > On Wednesday 26 September 2007 14:57:58 Jean-Francois Malouin wrote: > > I'm trying to understand how 'amfetchdump -i' works (amanda-2.5.2p1): > > At the moment, not all that well. :-( In theory, amfetchdump can be used to > recreate the Amanda logfile used to track which dumps were stored where. So > if your backup server bites the dust (and wasn't itself backed up), you can > use amfetchdump -i to restore the logs. After that, you will be able to use > amfetchdump to operate the changer and restore specific dumps. Note, however, > that amfetchdump -i will not restore the indices, so you'd still be unable to > use amrecover in that case. > > I have it on my plate to fix amfetchdump -i, but before I do so, maybe I > should ask for a show of hands: How needed is this feature, anyway? You mean the "do this to get what's needed for amfetchdump to work"? In my book it's absolutely essential! I would (I am now!) be very nervous to rely on a restore utility that would not work when things get real'bad. One of the most important feature of amanda was (it still is but read on) the possibility of doing a bare-metal restore with just a few utilities. I say was because in my case the ever increasing amount of data, the size of the DLEs and the number of chunks needed in order to fit in my tapes (LTO-1 and LTO-3) was getting out of hand --too much likely to 'forget' some data while including/excluding dirs in a DLE-- so I had to use the tape spanning feature. I get a much better tape usage but now I can't do bare-metal restores in case something real bad happens. I understand that I can't have both the cake AND the cherry but I would be hard pressed to justify using amanda to our computer people at my site when such an important feature is missing. But what is exactly needed by amfetchdump? The amdump and log files in the logdir? Sorry for the long tirade! Thanks, jf > > --Ian > > > gertrude:$ /opt/amanda/sbin/amfetchdump -i - left2 > > Doing inventory/search, dumps will not be uncompressed or assembled > > on-the-fly. Beginning tape-by-tape search. > > Scanning av24-2_left2_U00015L3 (slot 6) > > amfetchdump: Search of av24-2_left2_U00015L3 complete > > > > and it stops there. The debug file shows: > > > > amfetchdump: debug 1 pid 26463 ruid 0 euid 0: start at Wed Sep 26 13:50:29 > > 2007 amfetchdump: debug 1 pid 26463 ruid 105 euid 105: rename at Wed Sep 26 > > 13:50:29 2007 search_tapes(prompt_out=2, prompt_in=0, use_changer=1, > > tapelist=(nil), match_list=(nil), flags=0x5046c0, features=(nil)) > > search_a_tape: no desired_tape > > current tapefile_idx = -1 > > > > What is amfetchdump suppose to generate in inventory mode? > > > > If I use '/opt/amanda/sbin/amfetchdump -i log left2' I get > > 'amfetchdump: Couldn't open log file log for writing: Permission denied'. > > > > I guess I have to run it as the amanda user? > > > > thanks, > > jf -- <° ><
Re: amfetchdump - inventory mode
Jon,
Can you try the attached patch.
Jean-Louis
Jon LaBadie wrote:
I haven't used amfetchdump before and thought I'd try its
inventory mode, option -i. As I understand it, with this
option amfetchdump will examine the tapes (vtapes in my
case) and generate output showing the contents in a
syntax similar to logfile entries.
If I enter amfetchdump -i mylog tstvt
It gets to the virtual tape changer, slot 1 and seems to
try to start an inventory. But after a few seconds I
get the message:
Scanning vtape01 (slot 1)
amfetchdump: error reading file header: Input/output error
If I actually try to recover a dump from a specific host/date,
things seem to work properly.
When I looked at the tape in slot 1, due to wrap-around the
tape list, it was the second tape of an amdump run. It contained
only the last couple of chunks of a dump started on the last
tape in the changer.
So I wonder if this scenario, first tape in the changer starts
in the middle of a split file sequence, was considered in the
logic of amfetchdump's -i option. Have others gotten a successful
inventory under these conditions?
diff -u -r --show-c-function --new-file --exclude-from=/home/martinea/src.orig/amanda.diff --ignore-matching-lines='$Id:' amanda-2.5.2p1/restore-src/restore.c amanda-2.5.2p1.inventory/restore-src/restore.c
--- amanda-2.5.2p1/restore-src/restore.c 2007-06-06 19:19:20.0 -0400
+++ amanda-2.5.2p1.inventory/restore-src/restore.c 2007-06-19 15:42:41.0 -0400
@@ -1451,6 +1451,16 @@ search_a_tape(
}
dbprintf(("current tapefile_idx = %d\n", tapefile_idx));
+/* if given a log file, print an inventory of stuff found */
+if(flags->inventory_log) {
+ if(!strcmp(flags->inventory_log, "-")) logstream = stdout;
+ else if((logstream = fopen(flags->inventory_log, "w+")) == NULL) {
+ error("Couldn't open log file %s for writing: %s",
+ flags->inventory_log, strerror(errno));
+ /*NOTREACHED*/
+ }
+}
+
/* if we know where we're going, fastforward there */
if(flags->fsf && !isafile){
/* If we have a tapelist entry, filenums will be store there */
@@ -1501,7 +1511,7 @@ search_a_tape(
tempdump = alloc(SIZEOF(dumplist_t));
tempdump->file = alloc(SIZEOF(dumpfile_t));
tempdump->next = NULL;
- memcpy(tempdump->file, &file, SIZEOF(dumpfile_t));
+ memcpy(tempdump->file, file, SIZEOF(dumpfile_t));
if(tape_seen->files){
fileentry = tape_seen->files;
while (fileentry->next != NULL)
@@ -1660,6 +1670,9 @@ search_a_tape(
fflush(logstream);
}
}
+ if (logstream != stderr && logstream != stdout) {
+ fclose(logstream);
+ }
}
}
@@ -1684,7 +1697,6 @@ search_tapes(
int have_changer = 1;
int slot_num = -1;
int slots = -1;
-FILE *logstream = NULL;
tapelist_t *desired_tape = NULL;
struct sigaction act, oact;
ssize_t read_result;
@@ -1720,16 +1732,6 @@ search_tapes(
if(flags->delay_assemble || flags->inline_assemble) exitassemble = 1;
else exitassemble = 0;
-/* if given a log file, print an inventory of stuff found */
-if(flags->inventory_log) {
- if(!strcmp(flags->inventory_log, "-")) logstream = stdout;
- else if((logstream = fopen(flags->inventory_log, "w+")) == NULL) {
- error("Couldn't open log file %s for writing: %s",
- flags->inventory_log, strerror(errno));
- /*NOTREACHED*/
- }
-}
-
/* Suss what tape device we're using, whether there's a changer, etc. */
if(!use_changer || (have_changer = changer_init()) == 0) {
if (flags->alt_tapedev) {
@@ -1945,9 +1947,6 @@ search_tapes(
}
-if(logstream && logstream != stderr && logstream != stdout){
- fclose(logstream);
-}
if(flags->delay_assemble || flags->inline_assemble){
flush_open_outputs(1, NULL);
}
