On Thursday 27 June 2019 14:22:05 Debra S Baddorf wrote: > > On Jun 26, 2019, at 6:33 PM, Gene Heskett <[email protected]> > > wrote: > > > > On Wednesday 26 June 2019 17:54:12 Nathan Stratton Treadway wrote: > >> On Tue, Jun 25, 2019 at 03:45:15 -0400, Gene Heskett wrote: > >>> I tried to run amrecover on picnc, but was NAK'd at every step. > >>> This even though I have added the root line to > >>> /var/backups/.amandahosts. > >> > >> (Like so many aspects of Amanda, it's very likely possible to get > >> amrecover working on picnc -- but that's a whole separate > >> discussion, and since you have already retrieved the files you > >> needed, I don't know how worthwhile it is to go down that road at > >> this point....) > >> > >>> So I located the last full which was on the 16th, and using the > >>> usual dd if=/path/to/file._.0 bs=32k skip-1 | gzip -d | tar x - > >>> command, unpacked it to some spare space on the /amandatapes > >>> drive, then copied what I needed from that tree to > >>> /home/gene/linuxcnc/transfer-dir, > >> > >> The goal of my earlier message was just to point out that running > >> amrecover into a temporary working directory on the server is a > >> middle ground. With that approach, you let Amanda (via > >> "amrecover") manage all the inventory-of-dumps tracking and > >> unpacking of the files (including the possibility of limiting the > >> unpacking to only the particular subdirectories you care about)... > >> but without the need to worry about setting anything up on the > >> client side. > >> > >> (Obviously since you are skipping the client side setup you do > >> still need to copy the recovered files from the server over to the > >> client, but that process would be identical to what you just did > >> above, just starting with the directory tree created my amrecover > >> instead of the one created by "tar x".) > >> > >> But hey, if you don't mind building the dd/gzip/tar command > >> pipeline yourself, that certainly gets the job done too :) > >> > >> Nathan > > > > Just one big horsefly sized bug in following the directions in that > > files header. The last argument to tar was a 4 char string I've > > never seen before, and I watched it grind away at 100% of a random > > core for about an hour before I gave it a ctrl-c. Quit instantly and > > did no damage, so I up-arrowed and edited that string to just an x > > >picnic-slash. > > > > Since it was a good sized file, that also took a while, but gave me > > a filesystem I could walk thru to what I needed, and copy it out. > > And once I had the output, the rest was think, faster. But while I > > did get it, I feel like I should have been able to do it with > > amrecover. And I'm less than pleased. That _is what amrecover is > > for_ is it not? > > > > Thanks Nathan. > > Amrecover on picnc didn’t work, so you went straight to dd. > (Well, I frequently use dd too, but: ) > Did you try amrecover on the server node? Start yourself in a temp > area, amrecover <config>, > set host picnc > setdisk <whatever> ( / was it?) > cd one dir at a time. > extract > edit and copy files to client as needed > > If client is using tar, this should work fine. > If client is using dump, then server can only do this if server is > the same flavor of machine, using compatible restore program. But > I think you were on tar, so no sweat. This gets you the result > (minus final copying) entirely from amanda. > > Deb Baddorf > Fermilab
I expect, but wasn't thinking of that, but I think amrecover could probably have dumped the whole dle to some scratch space right on the same drive, doing essentially what I did. And I still would have had to copy what I wanted to an intermediate location where I could change the perms back to the target machine, then put then back where they belonged. But due to the poor choice of words in the man pages, I have difficulty tracking what a cd vs an lcd does, and pwm/lpwm suffer a similar problem. Some of that confusion could be alleviated by orthogonality between ls's, allowing one to see where you are in both the clients file structure and in the dle's structure. But it has no lls to match the lpwd. So you need to type blind, sort of a cuss and cry operation. Not at all conducive to achieving an "insitu" recovery. I realize the man pages are somewhat archival and make the assumption everone uses tape. But vtapes on a big hd are still about 1000 times faster and are random access. I suppose one could have more than one drive, and cycle them between local and offsite storage. And I see the planner is gradually adjusting things, it hasn't surprised me and actually used 2 "tapes" in a couple weeks now. So some progress is being made. I hope its a little cooler at your location, it 90F here and I think my AC might be needing a recharge. Take care Deb. 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>
