On Monday 01 July 2019 16:45:51 Nathan Stratton Treadway wrote: > 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 > I've got the lcd problem sussed I think, I was trying, from the server, this machine, to set the recovery (the "to" directory) to /sshnet/picnc//home/pi. But thats an sshfs mount done as me. But amrecover was running as root, and to "root" the /sshnet/picnc directory is empty. Part of my paranoia, root is locked away from the rest of the local network.
An nfs mount may not have had that problem. But over the years I've had so much file corruption with nfs that its probably been a decade since the last time I set up an nfs share here at the coyote.den. For me, sshfs Just Works. > > ---------------------------------------------------------------------- >------ Nathan Stratton Treadway - [email protected] - 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 Copyright 2019 by Maurice E. Heskett Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
