Design Consideration - Shared SQL DBs

[smudger]

Hi,

We are finalising our design for Backup&Replication and would envisage multiple proxy hosts (resilience, throughput, managability etc). On reading the installation notes it states it is possible to use SQL Express. We have a shared SQL co-host type environment for infrastructure applications and would prefer to use this as a solution.
My questions are:

- Is it possible for multiple proxy hosts to share the same remote SQL DB, or does each proxy host require it's own DB?
- Is using a shared SQL platform a common solutuion building block for larger environments?

Many thanks for any responses/feedback or experiences.

Regards,

Neil

[Gostev]

Hello Neil, no multiple hosts cannot use the same remote SQL DB - each host needs its own DB. Out of box, they can be on the same SQL server, but in different instances (because setup creates database with specific nice). It should possible to have then in the same SQL instance through manual procedure (manually rename database after it was created by setup, and update registry key with DB name on Veeam Backup server). Thanks!

[smudger]

Gostev,

Many thanks for the quick reply. A couple of things to feedback:

We have 6x proxy hosts targetting approx 500TB of data and having to finish the installation, have the DBA rename the DB, change the reg key is a major pain!

I'd like to see (and would appreciate if you could confirm this has been fed back to the Product team):

Short Term:
- The installer caters for multiple proxy host DBs and can add another DB with 1 or 01 so the installation can continue
- If this the above is not possible make the error handling inside the installer more intuative

Long Term:

-The product can use one DB for multiple proxy hosts (multiple attribute table or similar) allowing a medium or larger installation to be deployed quickly and easily ie. automated or image based deployment.

Thanks,

Neil

[Gostev]

Hello Neil, thank you for your feedback. I'll try to squeeze the short term solution in the 5.0 release. Thanks again!

[tim.vogel@xtium.com]

I would like to throw in my vote for this feature also. The ability to move jobs between different backup hosts to better balance the load is a critical piece that is currently lacking. Having to disable a job on one host and create(from scratch) the job on another is not a great solution and also requires a new full backup to be executed.

Hopefully this type of feature will make it to the critical functions list for some upcoming release.

[gh0stwalker]

Hi Gostev,

Are you able to supply the details of manually creating another Veeam database on a single SQL instance at all? Details of the location of the registry files that need editing and anything else appropriate would be great.

I'll also throw my vote in for making this a simpler process

Thanks
Dan

[smudger]

Dan,

I'm just finishing some "build & operations" guides for our Operational teams. The section on proxy host commissioning and working around the single DB per proxy hosts goes like this:

-After the installer has finished, stop the Windows "Veeam Backup and FastSCP" service
-Have your SQL DBA rename the newly created SQL DB (Default name: VeeamBackup) to "VeeamBackupX" where "X" is a unique number.
-Once the SQL DB has been renamed, the following registry key needs updating to the new SQL DB name - HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and FastSCP\SqlDatabaseName
-Once the registry key has been updated, start the Windows "Veeam Backup and FastSCP" service

Repeat the above for each new proxy server. I hope this helps and roll on a shared DB solution from Veeam in the next version

thanks,

Neil

[vbussiro]

Ouch... Could you give us some details on your 500 TB backup performance and config ?
And i'm whining to backup a mere 500gb...

[Gostev]

It's kinda cool when you can run your production on a single modern laptop with 500GB hard drive...

[smudger]

VBussiro, for some reason I'm not receiving further updates to this thread! PM me and I can walk you through our performance & config details.