As you say, most of these are possible, but some are relatively new features, so I'll mention them here for others' (and maybe your) reference.
On Thu, Sep 9, 2010 at 7:02 PM, Chris Lee <[email protected]> wrote: > 1. See if the client is installed and working on a server (From the point of > view of the Amanda Server it is backing up to) amservice can do this. > 2. See if that server is in the backup schedule Grepping 'amadmin $conf disklist' is one way to do this. You could also easily write a quick Perl script to do it. > 3. See what backups have been stored for that server and see where they are > stored now. amadmin $conf find $server > 4. Deploy the client to a remote server if I have login details. (Fair > enough I compile my own but if I had a few "packages" on the management > system then the correct one could be deployed) amaddclient does this, although as you suggest this cannot install Amanda on the remote system. > 5. See which Amanda Servers are configured with what tape storage Amanda's utilities don't address anything above the single configuration, let alone multiple servers.. > 6. Move clients from one Amanda server to another (Maybe with some > intelligent load balancing suggestions offered), (This also requires a > central view of backup history so that when moved the old backups are still > useful) Yikes, that's a hard one! > 7. Centrally managed tape types and backup types, so I do not have to copy > and paste to each and every new Amanda server. Does 'includefile' not do it for you? Perhaps with an NFS share if you need to share among multiple servers? > All of these are achievable now with scripts and some spare shoe laces but a > nice unified view would be great. > > Thanks for the opportunity to comment. It's good to hear - feedback is great. In general, comprehensive management tools are, charitably, a weakness of Amanda. While we've tried to add utilities where possible, the "comprehensive" part requires a lot of technical consistency that's just not in place just yet: a well-defined catalog, for example, and some way to make the disklist editable. Some of the features you've described are just not possible in an open source context and could only really be supplied in a commercial/enterprise context (for example, automatically installing Amanda on a client - that is a lot easier when the field of supported clients is limited and the packages are all available from download.yourcompany.com). My long-term project with Amanda is to make it more consistent. This is a major component of the Perl rewrite. This requires careful research to elucidate and document current undocumented behavior, detailed testing, forward-thinking redesign, test-drive re-implementation, crazy contortions for portaibility, and of course lots of debugging. All of which is fun (y'all should join in!), but not quick. So I'm invoking my "that's complicated" escape clause. The only one of these that I could conceivably accomplish in the 3.2 timeframe is #2. I could add 'amadmin $conf hosts' to list all of the hosts, avoiding the need to grep the multiline output of 'amadmin $conf disklist'. I'll put that in my queue right behind Chris H's suggestion (with which I'm almost finished). Thanks again, Dustin -- Open Source Storage Engineer http://www.zmanda.com
