Copy jobs - 99 copies limit

[Anders]

Hi everyone

Is there a way to get around the limit of 99 copies on copy jobs? I need to keep 180 off-site copies per copy job.

The keep deleted VM's can be set to 180 days - and its kinda strange why I can keep deleted VM's in my backup for longer than my production VM's.

Right now, the only way I can see, is to have 2 copy jobs, that each run every 2nd day and keep 90 copies each. But that would take up twice as much storage on the off-site, which is not really an option for me.

Can I maybe create the job with powershell and set it above 99, as it might be a GUI limit, or is there another workaround maybe?

Thanks,
Anders

[veremin]

Hi, Anders. For now, it’s neither possible to change this settings via GUI nor with PowerShell. Though, the limitation comes into play when you use only simple retention scheme and it can be bypassed if you try to leverage either GFS or two separate copy jobs.

[vincent]

Hi,

I've read the technical documentation about setting up the grandfather-father-son backup copy job, but I can't seem to figure out how to set it up.

I actually need to have 365 day's of retention. I want to go back at any given moment for a maximum of 365 days. I thought I would choose the following GFS settings:

Restore points to keep: 7
weekly backup: 4
monthly backup: 12
quarterly backup: 0
yearly backup: 1

Is the above correct?

My second question is how I can calculate the amount of storage needed for above configuration. My normal backup job is configured with reversed incremental keeping restore points for 30 days.

Many thanks.


Vincent

[veremin]

So, you're willing to store 365-worth continuous backup chain, right? If so, you should create additional backup job, instead of backup copy one, as the backup job doesn't allow to store more than 99 restore points (in case of simple retention) in order to avoid extremely long incremental chain.

Thanks.

[vincent]

I don't need a 365 continuous backup chain. I just want the ability to go backup 365 days for a maximum at any given point.
I thought I should use the grandfather-father-son method for accomplishing this?

[veremin]

Got it. Then, the plan provided above (12 monthly, 1 yearly backup) should give you what you're after. Thanks.

[vincent]

Is the weekly 4 also required? Or can I fill in 0.
And what about the storage needed. Can I calculate it like follows: Current full backup size x 12 monthly + 1 full backup for the yearly?

[veremin]

Is the weekly 4 also required? Or can I fill in 0.

Not, it's not required, you can leave 0 there if you want to.

Can I calculate it like follows: Current full backup size x 12 monthly + 1 full backup for the yearly?

+ Current full backup. So, you will roughly need the space for 14 current full backups.

Thanks.

[foggy]

I don't need a 365 continuous backup chain. I just want the ability to go backup 365 days for a maximum at any given point.

Just to make sure we're on the same page: do you need an ability to restore to any given day within the last 365 days? The fact is that , say, monthly backup in GFS scheme will allow to restore to the particular day when it was created only, not to any of the days within the month. So if you need to be able to restore to any of the days, you would need to keep continuous backup chain, as Vladimir has suggested above.

[vincent]

Ok I understand the above.

Could you specify a bit more in detail how I would setup the method Vladimir suggested, about the multiple backup jobs to restore to any given day within 365 days.

[foggy]

You just need to set up an additional daily backup job with 365 restore points retention. Don't forget to configure monthly active fulls to avoid extremely long incremental chain.

[vincent]

Either way. This is costing me a lot of storage.

[veremin]

In case of additional backup job, you can use reversed incremental mode. Not only does it reduce the space needed for hosting backup chain, but also it allows you to perform active full backup on less frequent basis.

Thanks.

[vincent]

For my normal backups for this customer I already use reverse incremental with 30 restore points.
The sum of all full backups = 1,4 TB at this point

I have 4 jobs. The directories of these 4 jobs contains incrementals between 5-30GB per incremental. That means if I take 20 GB as average size incremental:
20GB incremental x 30 days= 600GB x 4 directories containing incrementals = 2400GB x 12 months = 28800GB

The incrementals is costing me a ridculous amount of data. Am I calculating this right?

[foggy]

Yes, your calculations seem right. Still, this is a full year of daily backups, so definitely should take space.

[Dario.Palmisano]

Subject: Backup Copy restore points limit is 99, Backup restore points limit 999 - Case # 00512252

Hello,

I just wonder the reason why it is NOT possible to set up more than 99 restore points for a "Backup Copy" job, while for a "Backup" job it is possible to set up up to 999 restore points.

Many thanks
Regards
Dario

[veremin]

Hi, Dario,

Your post has been merged into existing discussion.

In general, the reason behind limiting number of backup copy restore points is to avoid extremely long incremental chain. If you're after protecting data for long period of time, please, consider using GFS retention scheme, instead of simple one.

Thanks.

[kwells]

Is there any way to increase the maximum number of restore points retained in the backup copy. I need to be able to retain data for ever, which I have sorted out by using NAS and tapes and a mixture of full and incremental backups with large number of restore points. I would like to keep as many restore points as possible on the (Large) NAS boxes, both on live and DR site. I noticed whilst setting this up that I can keep 999 points in the backup job, but only 99 in the Backup Copy Job. This seems a bit illogical. Surly a copy job should be the same as the job it is a copy of?