-
- Enthusiast
- Posts: 28
- Liked: 3 times
- Joined: Jan 14, 2015 7:01 am
- Contact:
Multi-Tiered Architectur for VBR setup
Hello everyone,
I am currently extending our Veeam infrastructure from one VBR-server (VBR-server-1) (DAS-SSD storage) to Multi-Tiered
Infrastructure will be:
Tier-1: Primary backup (short term): SSDs direct attached on VBR-server-1
Tier-2: Secondary backup (mid term): HDDs direct attached on VBR-server-2
Tier-3: Tertiary backup (long term archive): LTO5 Tape lib FC-attached to VBR-server-2
Plan:
1) Daily backups from production environment to Tier-1 via SAN
2) Midterm backups from Tier-1 to Tier-2 via Backup Copy Jobs (via LAN)
3) Archival backups from Tier-2 to Tier-3 via Tape Jobs (FC)
Short term: 30 restore points
Mid term: 4 weekly RPs, 3 monthly, 4 quarterly, 1 yearly
Long term: 1-10 years depending on data
How and where do I best configure this?
Primary backup obviously as Backup jobs on VBR-server-1
Secondary is currently (testing) configured on VBR-server-1 as well (with the remote repository being added on both VBR servers). This works good in terms of continuous schedule of Backup Copy Jobs
VBR-server-2 automatically imports detected backups on its repository (that have been filled by VBR-server-1's copy jobs)
But if I want to schedule Tape jobs I could only do that based on jobs (which are non-existent on VBR-server-2 of course) or file based (which might be unstable: in case paths change how would I realize that stuff does not get archived anymore)
Somehow I need to make sure the following:
- in the past tape-jobs got killed by disk jobs due to their backup-file-lock. This should be prevented.
- compute resources of the VBR-server-2 should be utilized as good as possible (e.g. for complete tape job handling)
- "deadlocks" between jobs should be prevented
- management and scheduling should be easy
Any suggestions?
I am currently extending our Veeam infrastructure from one VBR-server (VBR-server-1) (DAS-SSD storage) to Multi-Tiered
Infrastructure will be:
Tier-1: Primary backup (short term): SSDs direct attached on VBR-server-1
Tier-2: Secondary backup (mid term): HDDs direct attached on VBR-server-2
Tier-3: Tertiary backup (long term archive): LTO5 Tape lib FC-attached to VBR-server-2
Plan:
1) Daily backups from production environment to Tier-1 via SAN
2) Midterm backups from Tier-1 to Tier-2 via Backup Copy Jobs (via LAN)
3) Archival backups from Tier-2 to Tier-3 via Tape Jobs (FC)
Short term: 30 restore points
Mid term: 4 weekly RPs, 3 monthly, 4 quarterly, 1 yearly
Long term: 1-10 years depending on data
How and where do I best configure this?
Primary backup obviously as Backup jobs on VBR-server-1
Secondary is currently (testing) configured on VBR-server-1 as well (with the remote repository being added on both VBR servers). This works good in terms of continuous schedule of Backup Copy Jobs
VBR-server-2 automatically imports detected backups on its repository (that have been filled by VBR-server-1's copy jobs)
But if I want to schedule Tape jobs I could only do that based on jobs (which are non-existent on VBR-server-2 of course) or file based (which might be unstable: in case paths change how would I realize that stuff does not get archived anymore)
Somehow I need to make sure the following:
- in the past tape-jobs got killed by disk jobs due to their backup-file-lock. This should be prevented.
- compute resources of the VBR-server-2 should be utilized as good as possible (e.g. for complete tape job handling)
- "deadlocks" between jobs should be prevented
- management and scheduling should be easy
Any suggestions?
-
- Veteran
- Posts: 1943
- Liked: 247 times
- Joined: Dec 01, 2016 3:49 pm
- Full Name: Dmitry Grinev
- Location: St.Petersburg
- Contact:
Re: Multi-Tiered Architectur for VBR setup
Hi,
I'd recommend you to use a single backup server, as it allows you to manage and schedule jobs more easily than in situation with the two servers.
To prevent interruptions of the tape jobs you can use scripts that will put on hold backup jobs whilst it in the processing.
Short term plan you can set up by simple retention policy in the backup job settings.
For the mid term retention you should use GFS in the backup copy job wizard as it was designed exactly for such purposes. Thanks!
I'd recommend you to use a single backup server, as it allows you to manage and schedule jobs more easily than in situation with the two servers.
To prevent interruptions of the tape jobs you can use scripts that will put on hold backup jobs whilst it in the processing.
Short term plan you can set up by simple retention policy in the backup job settings.
For the mid term retention you should use GFS in the backup copy job wizard as it was designed exactly for such purposes. Thanks!
-
- Enthusiast
- Posts: 28
- Liked: 3 times
- Joined: Jan 14, 2015 7:01 am
- Contact:
Re: Multi-Tiered Architectur for VBR setup
Hello
using one VBR-server for scheduling implies two limits:
- Only one systems CPU/RAM ressources would be used
- How does it handle the repo attached to the other server?
Or does Veeam handle that smartly by realizing that the storage is on VBR-server-2 as well as the storage and having the second server do the work?
using one VBR-server for scheduling implies two limits:
- Only one systems CPU/RAM ressources would be used
- How does it handle the repo attached to the other server?
Or does Veeam handle that smartly by realizing that the storage is on VBR-server-2 as well as the storage and having the second server do the work?
-
- Product Manager
- Posts: 8191
- Liked: 1322 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Multi-Tiered Architectur for VBR setup
Hi chas0rde,
Consider the VBR-server as a "command and control" center. When you look through our documentation, you will notice that you can expand the solution by using different servers with different roles. For example, you would have a repository role on a second server that will store the data and also a proxy somewhere over there that does the heavy lifting. You can also create a role on a server that will be the TAPE infra role (and manage your tapes). There is a lot of possibilities that you can do with a single VBR server while the components that are distributed are doing the heavy lifting. And you can obviously use any windows server (with a supported OS) to deploy components on, and you can use one server that hosts multiple roles.
Consider the VBR-server as a "command and control" center. When you look through our documentation, you will notice that you can expand the solution by using different servers with different roles. For example, you would have a repository role on a second server that will store the data and also a proxy somewhere over there that does the heavy lifting. You can also create a role on a server that will be the TAPE infra role (and manage your tapes). There is a lot of possibilities that you can do with a single VBR server while the components that are distributed are doing the heavy lifting. And you can obviously use any windows server (with a supported OS) to deploy components on, and you can use one server that hosts multiple roles.
-
- Enthusiast
- Posts: 28
- Liked: 3 times
- Joined: Jan 14, 2015 7:01 am
- Contact:
Re: Multi-Tiered Architectur for VBR setup
Hello
so I would just install Windows on the VBR-server-2 and then add it as a managed server on VBR-server-1 in backup infrastructure. Afterwards I just select tape infrastructure and add that VBR-server-2 as Tape server.
It also hosts a repo for the mid-term backups. This would then also be backed up via backup infrastructure.
Then on VBR-server-1 I would configure the backup-copy with target: repo on VBR-server-2
And Tape Jobs with source: backup-copy on VBR-server-2
This would lead to the VBR-server-2 doing the heavy lifting to destil the tape backup from the (to it local) repo with the backup-copy jobs?
Best regards
so I would just install Windows on the VBR-server-2 and then add it as a managed server on VBR-server-1 in backup infrastructure. Afterwards I just select tape infrastructure and add that VBR-server-2 as Tape server.
It also hosts a repo for the mid-term backups. This would then also be backed up via backup infrastructure.
Then on VBR-server-1 I would configure the backup-copy with target: repo on VBR-server-2
And Tape Jobs with source: backup-copy on VBR-server-2
This would lead to the VBR-server-2 doing the heavy lifting to destil the tape backup from the (to it local) repo with the backup-copy jobs?
Best regards
-
- Product Manager
- Posts: 8191
- Liked: 1322 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Multi-Tiered Architectur for VBR setup
You actually don't need to add it as a managed infrastructure. Just deploy a role to server 2 and it will automatically become a managed server
Important is going to be the proxy role. That is the one that does the processing of jobs and moving of data. So read up on this one here: https://helpcenter.veeam.com/docs/backu ... tml?ver=95
Cheers
Mike
Important is going to be the proxy role. That is the one that does the processing of jobs and moving of data. So read up on this one here: https://helpcenter.veeam.com/docs/backu ... tml?ver=95
Cheers
Mike
Who is online
Users browsing this forum: Google [Bot], Gostev and 65 guests