Avtar Command Line Backup Questions

Please consider moving this question as-is (no need to recreate) to the proper forum for maximum visibility.  Questions written to the users' own "Discussions" space don't get the same amount of attention and can go unanswered for a long time. 

You can do so by selecting "Move" under ACTIONS along the upper-right.  Then search for and select: "Avamar Support Forum".

Sorry. Thought I had created it in the Avamar support forum to begin with. Must not have clicked on the link.

It is not possible to back up a system by running an avtar command on a different system. The avtar command will back up the system where it is running, so it is very likely that you have inadvertently backed up the filesystem of the Avamar utility node to this client account.

If you need to run backups of remote systems from the command line, you are probably looking for the mccli command.

Take a look at the Avamar MCCLI Programmer Guide:

Avamar 6.0 MCCLI Programmer Guide

Avamar 6.1 MCCLI Programmer Guide

Thanks for the reply. I'd started looking a bit at the MCCLI commands and got the remote client to backup but the problem I have is being able to set the appropriate retention now when the backup runs. I looked at the "mccli client edit" command and tried modifying the retention using that command but no luck.

From what I understand the "mccli client edit" command can set options on the client so that if a specific dataset is used with a specific retention policy then that will override the "None" that the on-demand backup retention will be set to but that doesn't appear to be working. Maybe I've got something screwed up in my syntax and am missing an option? I'm using this command:

mccli client edit --dataset=Test_Laptop_Dataset --domain=/Serverdomain --name= --retention="Policy and Financial"

I'm also wondering if I need the "--override-cis-retention=true" option or if my problem is the "Policy and Financial" in the retention setting?

Thanks.

Editing the client directly will only override the dataset, retention, etc. for scheduled backups (and then only if the appropriate override-* option is set to true -- override-dataset, override-retention, etc.).

The way I would approach this is to create a new group for the affected client(s), configure the appropriate dataset and retention for this group, then use the "mccli group backup" command to initiate the backup as needed. Using this approach should force the backup to run as a scheduled backup so the correct retention will be applied.

Alternatively, you could kick off the backup manually using mccli client backup-dataset or one of the related commands and alter the retention tags and expiration date using mccli backup edit after the backup completes.

Please let me know if you run into any issues.

It's possible to install mccli on an external system running Red Hat. The MCCLI guide has steps on how to do this. Presumably it would work on CentOS as well but that's not officially supported.

I have also seen customers set up scripts using tools such as Plink to connect to the utility node and run the mccli commands remotely.

My pleasure!

I created a new policy for this backup and set the appropriate dataset, schedule was the "on-demand" schedule, retention policy was the appropriate retention policy. When I ran the backup using the "mccli group backup" command specifying this policy the backup ran but the retention was still set to "N" instead of the retention I'm wanting.

At this point I'm thinking I may have to use the combination of the mccli client backup-dataset and then alter the retention. The good thing is that the replication doesn't happen immediately so I should be able to set the retention before the replication to our DR grid happens. I don't want to get them out of sync.

One of the problems I see with this is that I don't want our night operator logging into the utility node to kick off these backups. Can I use a script language like PowerShell to create a script that will call the appropriate mccli commands?

Thanks.

So in order to get the retention I want I'll have to modify the "Daily", "Weekly", "Monthly" and "Yearly" retentions to get the retention I want?

The retention tags and backup expiration are assigned at backup creation time. For scheduled backups, the expiration is set at backup time based on the retention tags applied (Yearly overrides Monthly, Monthly overrides Weekly, etc.). After backup creation, you would have to set the appropriate retention tags and update the expiration -- the expiration will not be modified just because you modify the retention tags.

That's correct, yes. You can retrieve most (all?) mccli output in XML format by specifying the --xml parameter if XML is a better format for you, e.g. mccli backup show --name=/clients/testclient.example.com --xml

So basically I'll have to update the backup twice, once to set the appropriate retentions (D,W,M,Y) and then update it again to set the expiration date according to largest retention.

Example:

Set the retention to Daily, Monthly on a month end backup then set the expiration date to backup date + 1 year since that's the retention we want on some of our monthly backups.

Now I just need to see if I can get the LabelNum from the "mccli backup show" in my script so I update the proper backup.

I have set up public / private key authentication in the past. You can use change-passwords to authorize additional public keys.

Is there documentation on how to do this? I'm reading a document on plink and it says to modify the authorized_keys2 file but when I do that file is readonly. I don't want to screw something up.

Thanks.

So I'm playing with plink to see if I can get it to log into the utility node. Have you ever tried setting this up to use public/private key authentication? I really don't want to have to enter the password when the job runs.

Thanks.

Essentially you need to generate a keypair on the machine where the script will run, then use change-passwords on the Avamar utility node to add the public key from that keypair to the authorized_keys2 file. I believe change-passwords is documented in the Administration guide.