This <https://wiki.zmanda.com/index.php/Backup_client_(old)#Chris_Hoogendyk.27s_Example> is a bit
dated, but may give you an idea of how to attack it. However, it could be that with the api work
that Dustin did there is a better way of doing this with the newer versions of Amanda. I'm not on
Solaris anymore, and I've updated most of my Amanda installations, so I haven't been using this
wrapper for some time.
On 11/15/18 2:22 PM, Chris Miller wrote:
Hi Brian
*From: *"Cuttler, Brian R (HEALTH)" <brian.cutt...@health.ny.gov>
*To: *"Chris Miller" <c...@tryx.org>, "amanda-users"
<amanda-users@amanda.org>
*Sent: *Thursday, November 15, 2018 10:54:49 AM
*Subject: *RE: Clients that return something else
Why pipe dd to tar when you can just run tar?
Good question. tar works at the filesystem level but dd works at the disk block level and I'm not
aware of any way that tar can create a disk image, so I need to read the disk with dd. AMANDA
expects a tar saveset, so I need to pipe anything I create to tar.
Er – I think the answer is “yes”, but you may have to roll your own.
Yeah, so do I. I'm just not exactly sure how I tell the client what to do. It appears that the
dumptype uses something symbolic, and leaves the client up to its own devices to determine what it
means. I could also do this, but I'd really like to be able to define the script on the server.
Also, it's not exactly clear to me how the client understands what "GNUTAR" or "DUMP" means
locally -- something must see "GNUTAR" and conclude, "Oh, he wants to run /usr/sbin/tar". For
example, if I could put "BASH" in my dumptype definition for "program", and include that code
somehow, that would be perfect! Ever hear of anything like that?
Thanks for the help, Brian.
--
Chris.
V:916.974.0424
F:916.974.0428
--
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geosciences Departments
(*) \(*) -- 315 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogen...@bio.umass.edu>
---------------
Erdös 4
