On Mon, Jul 01, 2019 at 15:28:53 -0400, Gene Heskett wrote:
> Explain to me, what lcd vs cd does? What filesystem does each represent?
"cd" changes the working directory in the virtual filesystem built from
Amanda's index catalog. You will definitely need to use this command as
part of your amrecover session (except in the case where you actually
do want to restore an entire dump in full, anyway).
"lcd" changes the "local" working directory, i.e. the one amrecover will
write the recoverd files into. As long as you change into your recovery
directory (e.g. using the "cd" command from your shell prompt, as shown
in my sample transcript) before entering amrecover, you can completely
ignore the "lcd" command.
> And why is there not an lls to list whats at the point of a successful
> lcd, like an ls does for a cd?
I can't tell you for sure why amrecover was originally written the way
it was, but I suspect it might have been modeled after the standard Unix
"ftp" client program, which was probably a very familiar file-transfer
mechanism when amrecover was first written...
(I'm sure there are many versions of that floating around, but I think
the "traditional" version has an "lcd" command with the same meaning as
the one in amrecover, and does not have "lls".)
You can of course always just check the contents of the directory listed
in the output of the amrecover "lpwd" command using a shell in another
terminal window... but in general I usually restore into an empty
recovery directory (as shown in my example transcript), and as a
side-effect of that I never have to wonder what currently exists in that
directory :) .
> One or the other didn't work, I've forgotten which and not being able see
> where I was, and verify which filesystem was what got so confusing I
In the transcript you posted, it was the "lcd" command that failed;
that was because the /home/pi did not exist on coyote (where you were
running amrecover). As long as you are recovering on the server side, I
think you will just want to restore into a recovery directory (and thus
avoid the need for using "lcd").... (Note that if "/home/pi" DID
actually exist on coyote, you would have dumped copies of the files from
picnc on top of it -- presumably not what you would have intended....)
> gave up and used a variation of the first blocks command line to extract
> the whole 7+gigs of picnc's /, then I walked thru it with mc and copied
(Exactly; if you use amrecover to select just the few subdirectories you
want to recover, you avoid recovering all the 7GB of other unneeded
stuff...)
> And FWIW, the commandline in block 1 of the file is bogus, eats cpu
> like they were M&Ms, and 20 minutes of bouncing from core to core
> didn't output a single byte, so I turned the last tar command in that
> pipelined chain around to 'tar x -', and had
(The GNUTAR program has used a few different sets of options for "tar"
over the course of various versions, and I'm not sure which you were
seeing.... but in your case, since you were recovering the files into
an empty directory and then manually moving them, including setting file
ownership/permissions, onto the client machine, I suspect that any
additional options listed in the header command line wouldn't have added
any useful functionality on top of the basic "tar x -" line you used....
[Also, while I won't try to claim that amrecover always works without a
hitch, in general if you use amrecover it takes care of figuring out
the correct recovery command to use, thus saving you the trouble :) .])
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
