Adaptative Active Full backup (Maybe feature request)

[Ctek]

Hi,

My objective is to minimize merges on the repositories (Using incremental backups) by using active full backups but also minimize the quantity of used data. I try to use active full backups, which saves a lot of IO at the merge process and uses a little more data on the repository but the limited active full scheduling options cannot let me optimize it. This is also to let us do tape backups of the active fulls without any time constraint. The solution that worked best on paper for us was Synthetic full backup with transform, but this kills our repositories.

In my situation, I need 9 restore points at minimum, and by scheduling a weekly active full, this creates a total of 3 active full backups in the cycle. A nice option, while maybe obscure, would be a adaptative active full where an active full backup is created when the end of the retention cycle is reached. In this case, there will be a maximum of 2 active full in my cycle, the first one, and the last one of the retention cycle.

Or, maybe I am missing out on something and I am not using these methods properly?

[Shestakov]

Hi Danny,
That`s a good feature request that makes sense in terms of full backups number. Currently the option is not available via UI however you can schedule the corresponding powershell script to run once in 9 days.
It should do the trick. Thanks for the feedback!

[veremin]

Generally speaking, active full backup cycles tend to take longer that incremental cycles do. Thus, people typically plan to run it on selected days devoted to that goal.

Having no control on when full backup occurs (with every X day schedule the exact day will certainly vary) sounds not that existing to me. Even less existing given various secondary jobs that are dependent on a primary one.

Thanks.

[ginux]

Hi,

My objective is to minimize merges on the repositories (Using incremental backups) by using active full backups but also minimize the quantity of used data. I try to use active full backups, which saves a lot of IO at the merge process and uses a little more data on the repository but the limited active full scheduling options cannot let me optimize it. This is also to let us do tape backups of the active fulls without any time constraint. The solution that worked best on paper for us was Synthetic full backup with transform, but this kills our repositories.

In my situation, I need 9 restore points at minimum, and by scheduling a weekly active full, this creates a total of 3 active full backups in the cycle. A nice option, while maybe obscure, would be a adaptative active full where an active full backup is created when the end of the retention cycle is reached. In this case, there will be a maximum of 2 active full in my cycle, the first one, and the last one of the retention cycle.

Or, maybe I am missing out on something and I am not using these methods properly?

I had the same necessity. I have 8 jobs (about 300 VM, divided by OS) that run "in chain" (the second start when the first has finished, ...); sometimes the schedule for active full comes to late for that job due to datastore or destination traffic and so the chain became too long. Should be fantastic if you could introduce an "automatic timer" that automatically place an active full after a certain number of incrementals. Another feature should be the possibility to choose another destination for the active full after a certain number of copies; for an example: mounthly backup chain made by Active Full on December splitted to another location (es. for annual vaulting), incremental from January to November... I've considered GFS schema, but it is not so suitable to my company policies

[Shestakov]

Hello Gino and welcome to the community.
Note that job chaining is not considered as best practicein comparison with parallel processing.
GFS for primary backup jobs is a frequent request which may be implemented in future versions.
Thanks!

[ginux]

Hi Shestakov,

thanks for your reply. I know that job chaining is not as good as parallel processing but after tests made on v.8 I've found it the best solution because it use all resources (cpu, network bandwidth and proxyes) for a single job... I will retry on v.9sp1 and make comparisons. Another question... do you think GFS for primary backup job will be implemented on v.10? To be more precise... it will be a major or minor release? Waiting for this new improvement I was thinking to use it as primary backup job... what do you think? Ops... my infrastructure:

vmware farm 5.5 on 2 sites in BC made of:
- 4 HP 7000 enclosures (2 per site)
- 2 HP 3PAR SAN (1 per site)
- every site connected to the other via ISL 10Gbps
- Veeam phisical HP server connected via HBA to SAN (4Gbps) and EMC DataDomain DD2500 via HBA (4Gbps)

thanks again for your help and patience

[Shestakov]

Gino,

Another question... do you think GFS for primary backup job will be implemented on v.10? To be more precise... it will be a major or minor release?

I can`t give any promises about that. The feature is not considered as major since initially it goes against our general recommendations. However, due to amount of requests it was taken back into consideration.

Waiting for this new improvement I was thinking to use it as primary backup job... what do you think?

As explained in the hyperlink above, GFS for primary job is not considered as best practice since you need to have a copy of backup data offsite for full protection.
Thanks!