how to set retention on replication target ?

Hello,

Yes, --expiredelta will increase the retention period on the target system, you can remove it from repl_cron.cfg if you don't need it.

To reduce the retention period on the target, you can use the /usr/local/avamar/bin/modify-snapups script available on the Avamar server
You could use something like:

modify-snapups --mode=expire --days=7 --domain=/REPLICATE/xxxxx/clients/

The above could be run as a cron job, the ideal time would be when you are sure replication has completed and before GC runs.

Hi Sandeep,

  Yes this will be a solution but in this time source avamar try to replicate all backups everyday. I mean modify-snapups script will delete all backups on target  everyday but  source avamar will try to send deleted backups again , right ?  and this behavior will be increase replication window duration.

  By the way we will add this job to dpn user`s crontab right ?

Thanks.

Hi Can,

Yes, that's right. Source avamar will try to send deleted backups again

To stop this, you may set up repl_cron.cfg to replicate just the last 7 days of backups. Edit repl_cron.cfg and add this line :

--after=`date -d '7 days ago' +%Y-%m-%d`

and then save repl_cron.cfg

Hi Sandeep

If I want to try this solution for One Client in the production environment, to testing do i have to make changes on the repl_cron file to exclude the client and created new repl_cron file and include this client

Please suggest

If this is not an urgent need and you're willing to upgrade once Avamar 7 is released, I would recommend waiting for that release. There have been many improvements made to the replication management features in this release, including the ability to more finely control the retention of backups on the replication target.

If this is urgent, I would recommend working with support to set up the second replication job.

Good news.

Hi Ianderson,

I execuited the following command

expire-snapups  --date=5  --domain=/Test, the output of the command show the retention of the client has been changed to 5 day, but the MCS GUI does not reflected the changes(I mean It still show the the retension as 60 days).

As the DPN summary report did not reflected the change.

Do I need to run other command after running the above command to update the MCS database

The expire-snapups command does not make changes directly since it has the potential to be destructive. When using expire-snapups, you should direct the output to a file, review the contents of the file to verify:

• The correct clients were selected
• The correct backups were selected
• The new retention is the intended retention

Once you have verified that the script is what you intended, confirm that the system is in full access mode (no maintenance jobs running, essentially), then mark the script executable using chmod and run it with:

nohup &

It is not necessary to take any action to update the MCS database. Backup expiration is controlled by the GSAN, not by the MCS (though the MCS can ask the GSAN to alter expiration settings if the user requests this through mccli or MC-GUI, obviously). The DPN Summary is a report based on the status of the backups at the time they were created or replicated and may or may not be updated with the new retention values. I have not had a chance to test this.

Hi ianderson,

thanks for your reply

Then how do i know that the retention has been changed. Is there any way we can confirm that the retention for that client has change. since the MCS and DPN summary does not  reflect.

The MCS retrieves backup expiration dates from the GSAN in real-time. The expiration displayed in the GUI's backup management section is the current expiration date.

Oh yea, one more thing. You have to couple that script with the --after command on the source grid from Sandeep's post above. Those 2 things have been working for us really well. You can go look at the expire.sh to see the script that did the work on the target grid, and look at the expire.log to see the results of the commands. Just |grep for MODIFY.

We have 6.1.1-87. Every time you have a patch applied, you might have to go back and edit that path in the delete-snapups perl script.

This might work for you until the promises in version 7 are GA.

We've been using this script for over a year now:

root@ :/usr/local/avamar/bin/ #: cat expire_old_backups.sh
rm -f /usr/local/avamar/bin/expire.sh
rm -f /usr/local/avamar/bin/expire.log
sleep 70
/usr/local/avamar/bin/delete-snapups --after='400 days ago' --before='15 days ago' --domain=/REPLICATE/ > /usr/local/avamar/bin/expire.sh
sleep 70
chmod 777 /usr/local/avamar/bin/expire.sh
sleep 70
source /usr/local/avamar/bin/expire.sh > /usr/local/avamar/bin/expire.log 2>&1
root@ :/usr/local/avamar/bin/ #:

Just know that you have to edit the delete-snapups perl script (in red) to add the full path to the mccli backup delete command so root's cron can find the command. you might have to edit that in 2 places.

    my $shellcmd = sprintf( "/usr/local/avamar/bin/mccli backup delete --domain=%s --name=%s --labelNum=%s --created=%s --force=true",

Just an FYI, Avamar 7.0 SP1 went GA a couple of days ago.