using mccli to keep the last backup of a client

Hello William,

After researching on your requirement, I can see no other way to change backup retention of clients using mccli.

"mccli backup edit" is only one command which can be used to change the retention. There are several other options to use this command. I am providing you details of all options. You can try these options as per your requirement.

mccli backup edit [--contained-vm-name=STRING] [--created=STRING]

[--domain=STRING(/)] [--expiration=STRING |

--extend-expiration=STRING | --retention=STRING]

[--force=Boolean(false)] [--labelNum=INTEGER] --name=STRING

--contained-vm-name=STRING

Specifies a virtual machine client within a VMware container or vApp. This option is only valid if the client specified by the name --name argument is a VMware container or vApp.

--created=STRING

Specifies the date the backup was created. STRING must be in the format of YYYY-MM-DD, where YYYY, MM, and DD are

calendar year, month, and date, respectively.

[--domain=STRING(/)]

Specifies the Avamar server domain that contains the client specified by the --name argument.

--expiration=STRING

Specifies a new expiration date. STRING must be of the following:

• YYYY-MM-DD is a specific year (YYYY), month (MM), and day (DD).

• NO_EXPIRATION specifies that the backup should never expire.

The --expiration, --extend-expiration, and --retention options are mutually exclusive.

--extend-expiration=STRING

Extends the existing expiration date. STRING must be in the format of +nn{D | W | M | Y}, where:

• +nnD is the number (nn) of additional days (d) to be added to the existing backup expiration date

• +nnW is the number (nn) of additional weeks (w) to be added to the existing backup expiration date

• +nnM is the number (nn) of additional months (m) to be added to the existing backup expiration date

• +nnY is the number (nn) of additional years to be added to\ the existing backup expiration date

The --expiration, --extend-expiration, and --retention options are mutually exclusive.

--force=Boolean(false)

By default, if you attempt to edit the retention type for a backup that has more than one retention type assigned to it, a

warning is issued and the retention type is not edited. If true, the checking is disabled and the backup is edited regardless of the number of retention types assigned to it.

--labelNum=INTEGER

Specifies the label number of the backup to change.

--name=STRING

Specifies the client from which the backup was originally taken. This argument is required.

If you supply a fully qualified client name (for example, /clients/MyClient), the --domain argument is ignored.

--retention=STRING

Specifies the retention types to assign to the backup. STRING must be one or more of the following values:

• D or daily

• W or weekly

• M or monthly

• Y or yearly

• N or none

Both short form and long form retention type values are allowed and can be mixed. For example, all of the following are

valid:

• --retention=D,weekly

• --retention=none

• --retention=Daily,W,monthly

The --expiration, --extend-expiration, and --retention options are mutually exclusive.

Event Codes

22236 Client does not exist.

22552 Backup does not exist.

22556 Changed backup retention.

22557 Failed to modify retention of a backup.

22558 Multiple retention tags exist.

Regards,

Pawan

There is a feature in Avamar that allows you to retain the last backup without the need to adjust its retention value.

1. edit file /usr/local/avamar/var/mc/server_data/prefs/mcserver.xml

2. Locate string “keep_last_backup” and change its value to “true” it should look like this:

3. stop & start the mcs service using dpnctl stop mcs then dpnctl start mcs

Once the above parameter is set the most recent backup of all clients will be locked and cannot be deleted until another backup is performed against the client.

Note: please be careful when editing the mcserver.xml file, make a copy of it first.

Adam, can you tell us how that affects the backups of retired servers?

After testing in a lab environment I found it treats retired BU’s in the same manner as regular BU’s where the most recent BU will be locked.

If multiple BU’s exist for a given client retired or not, these will expire normally but once it gets to the most recent BU it will be locked & retained regardless of its defined expiry date.

if you try to manually delete a locked BU using avtar, mccli or the GUI it will not perform the deletion.

There is a way to manually delete a locked BU but I’d advise you to engage support for assistance with that as the command used is not recommended for customer use.

Hello,

Thank you for your answer.

I didn't know the new option “keep_last_backup” in file /usr/local/avamar/var/mc/server_data/prefs/mcserver.xml.....

I have another question :

When the option "keep_last_backup" will be "true", I suppose the last backup snapup will be kept....  But sometime, I have problem of backups, with 10020 error code, and the backup size isn't good (for example 10Mo instead of 300Mo).

On the "Backup History", I can see the 30 snapups (retention of 30 days), but one is bad...

If the last is bad, how can I do ?

With my comand "mccli backup edit", I can test if the backup image is correct or not.

Thanks a lot

Adam,

Thank you for your answer to my question on this a well.

That shows there is a big caveat to using the option.... in the fact that you would keep the last backup of EVERY server - even retired servers - and the only way to get rid of them is to call support.

So use if the option really needs some thought put into it.

The original intention behind this feature was to ensure that there is always a backup available as a "seed" for future backups even if a desktop or (especially) laptop client goes offline for an extended period of time -- long enough that all of its backups would have otherwise expired. The feature was intended for DTLT clients, not for infrastructure clients.

It has some other caveats as well -- if a client is a member of two groups (let's call them "File System" and "Super-Important Exchange Database", it will create two backups every day. Only one backup will be locked. I'm sure you can see how this might not work out well.

thank you for answers !

I'm going to activate the "keep_last_backup" option but I don't know what to do if the last backup image is bad...

How can I do for a retention of 30 days, if the last backup is bad, but avamar kept the backup image (for example 29 backups with 200Mo and the last with 20Mo).