Handling media pools for off-site strategy

[kappa85]

Hi,
we successfully deployed Veeam 8.0 performing backups of our Hyper-V VM on a local repository. We setup some jobs with different retentions based on the VM role, with incremental daily and full weekly. We are doing some tests with a TL 2000, we installed it and tried to configure a few backup-to-tape jobs, it basically works well but now we have to configure our strategy. Our goal is the following:
- run a weekly full backup on friday and export it offsite
- keep 3 monthly tapes
- keep 1 yearly tape
So, I am a little bit confused about media pools and media set, I can't understand how many of these I have to setup. Before working with Hyper-V we used BackupExec to backup a lot of physical servers and we used a GFS strategy, with 4 sets of 5 tapes for daily incremental (MON1, TUE1, WED1..., MON2, TUE2, WED2..., MON3, TUE3, WED3..., MON4, TUE4, WED4...) then 4 montly and 1 yearly tape.

We'd like to replicate this configuration on the new environment, excluding incremental daily because we already have them on repository, we only like to export offsite the full weekly (or monthly, or yearly...). The only thing I think to understand correctly is that I need to use synthetic fulls, am I wrong?

Can someone clarify this?

[veremin]

You might want to

- switch your backup jobs to forward forever incremental mode
- create two media pools with different retention periods: 3 months, 1 year
- create two backup to tape jobs with different schedules: weekly (once a week), monthly (once a month)
- point them to the newly-created media pools accordingly
- enable virtual full backup

Thanks.

[kappa85]

Thank you. Only a few clarifications:
1) the forward incremental mode for backup to disk jobs is really necessary? Can you explain why?
2) what about media sets? Consider that I'm starting tape backup from scratch, I have only inserted 10 tapes and they are all in "unrecognized" category under "Media pools".
3) reagarding the link you provided about virtual full backup, the desired solution for me would be the one I see in the first picture, but I can't understand if I can schedule the virtual full backup just before putting it on tape. In that example the virtual full is made on thursday... incrementals performed on friday and saturday are lost?

[veremin]

1) the forward incremental mode for backup to disk jobs is really necessary?

Nope, it is not. However, other backup modes require periodic full backups that would be also copied to tapes, when time comes. So, during a year, there will be several additional .vbks archived to mediums.

2) what about media sets?

There is a description of media set. Set the settings that meet your expectations best.

3) reagarding the link you provided about virtual full backup, the desired solution for me would be the one I see in the first picture, but I can't understand if I can schedule the virtual full backup just before putting it on tape. In that example the virtual full is made on thursday... incrementals performed on friday and saturday are lost?

The easiest option would be to make that virtual full creation date coincide with date when backup to tape job runs.

Thanks.

[kappa85]

Thank you. I think I have correctly configured my tape environment, but... what about the supersedence of the monthly job on the weekly job? That is, I configured the Weekly job to run every friday, and the monthly on the last friday of the month. Is it possible to say "today is the last friday of the month, run only the monthly and not the weekly"?

[Dima P.]

Hello,

Is it possible to say "today is the last friday of the month, run only the monthly and not the weekly"?

Unfortunately, it’s not possible - so at certain days when you have both jobs running you will get one duplicated restore point.

[veremin]

Moreover, even if you disable an execution of particular job on a certain day via Powershell, next time it runs it will copy two .vbks (current one and the one it has not copied before).

However, according to the plan, tape GFS is planned to be introduced in the next product version; might be exactly what you're looking for.

Thanks.