Using NetBackup7 and NetApp's Snapmanager for Exchange on same instance and on VMware
Published:
Browse All Articles > Using NetBackup7 and NetApp's Snapmanager for Exchange on same instance and on VMware
We planned to use NetApp's SnapManager for Exchange (SME) to make three snapshots a day for quick recovery. Additional we planned to use Symantec NetBackup7 to backup to tape media for disaster recovery. We followed the best practice guide from NetApp for storage layout.
We run into the problem, that after doing the first snap, netbackup was not able to backup any more.
After a longer research together with our distributer for both products, we found the reason:
With the best practice described by net app, we have one volume with one LUN inside for each exchange data base and one volume with one LUN per database to store the transaction logs as also the SME file structure.
If you start the first snap, SME will create hard links to the logs inside his sub directory. Netbackup can not handle these hard links and the next backup with netbackup will fail.
To solve this problem, we separated the log directory from the SME directory on own LUN inside the same volume, which contains already the "old" LUN for the logs.
So now we have one volume with one LUN for each database (as before) and one volume with all log LUNs and SME LUNs - two LUNs for each database.
By the new storage layout we run into a new problem, because our exchange infrastructure is hosted on VMware as virtual machines (VM) . Every VM can only contain 3 SCSI-Adapters, with a maximum of 15 drives (LUNs) each. This gives a maximum number of 45 LUNs for each VM. Not enough for our 16 databases.
To solve this, we reduced the number of databases to 14 at all and come to 42 LUNs for data and one more for the operating system.
(One more time "42" is the answer ;-) )
We run into the problem, that after doing the first snap, netbackup was not able to backup any more.
After a longer research together with our distributer for both products, we found the reason:
With the best practice described by net app, we have one volume with one LUN inside for each exchange data base and one volume with one LUN per database to store the transaction logs as also the SME file structure.
If you start the first snap, SME will create hard links to the logs inside his sub directory. Netbackup can not handle these hard links and the next backup with netbackup will fail.
To solve this problem, we separated the log directory from the SME directory on own LUN inside the same volume, which contains already the "old" LUN for the logs.
So now we have one volume with one LUN for each database (as before) and one volume with all log LUNs and SME LUNs - two LUNs for each database.
By the new storage layout we run into a new problem, because our exchange infrastructure is hosted on VMware as virtual machines (VM) . Every VM can only contain 3 SCSI-Adapters, with a maximum of 15 drives (LUNs) each. This gives a maximum number of 45 LUNs for each VM. Not enough for our 16 databases.
To solve this, we reduced the number of databases to 14 at all and come to 42 LUNs for data and one more for the operating system.
(One more time "42" is the answer ;-) )
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)