> On Jun 26, 2019, at 6:33 PM, Gene Heskett <ghesk...@shentel.net> 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
