DiRT UnityDBBackUp.sql sizes differ between Primary and Failover

[jifitzge]

We recently upgraded to Unity 4.0.4sr1 from 4.0.2 and started running DiRT on the failover (per the Unity admin guide) in addition to the primary server. Now the DiRT files from the Failover are much smaller then the DiRT files from the Primary. The UnityDBBackUp.sql on the primary is 120,000 KB and the UnityDBBackUp.sql on the failover is only 50,000 KB. I realize there are links in the primary that aren't in the failover, but the discrepancy has me a little concerned. Has anyone else experienced this? Is it normal? Any feedback would be appreciated.

Thanks,

Jim

[Hin Lee]

Hi Jim:

I ran DiRT backup on both Primary and Failover server and can confirm that the Primary's UnityDBBackup.sql is larger in size than Secondary's.

Check the DiRT backup logs to see if there are any problems. Check the application logs to make sure you don't have replication issues.

[Hin Lee]

http://www.ciscounitytools.com/HelpFiles/UnityDisasterRecovery.htm#_Toc86115082

Backing up and Restoring Systems Configured For Fail Over

If you have two Unity servers configured for fail over it’s best to backup the Unity server configured as the fail over server, not the primary if possible. The primary Unity server will have additional links in SQL setup for replicating to the fail over server database and these links will be broken when you restore to a new server. If you then try to reconfigure fail over capabilities on that server it will fail. There’s no way to automatically remove these flags from the backed up database so if you have backed up the primary Unity server you will need to manually clean up the SQL properties after restore. The DiRT restore notices the fact that the restored database has these links and will pop up a warning dialog at the end of the restore reminding you of these (probably why you’re here reading this now). The steps to clean up the SQL replication links are as follows:

[jifitzge]

Thanks Hinho,

Thats how I discovered the size discrepancy. My concern was how large the size disceprancy was between the PRI DiRT and the FOVR DiRT. We had some unusual FOVR issues when we were running 4.0.2 so for now I think we'll continue to run DiRT on both the PRI and the FOVR and hopefully the FOVR will be used if we ever need to perform a restore. Any idea on why the sizes differ by so much. I wouldn;t think SQL replication links would be significant. is it based on number of local subscribers or AD size in any way?

[lindborg]

I think what he's asking, though, is why the sizes of the DBs are different on the primary and failover boxes.

DiRT is using the built in SQLDMO libraries to back up the entire UnityDB database (and optionally the ReportDB database) - so what you're seeing is actually not just a compressed binary table of data (i.e. like a big Access MDB file) but a base with a bunch of transactions that are applied to it to bring the data to where it was backed up - these transactions are not stored/applied the same on the primary and failover - the failover box is "synched" changes on the primary, but the primary is taking changes "as they come" - the space the transactions take up will then vary.

So the fact that the database backups of each is different is actually nothing to be too concerened with - they will never be exactly the same size. There's no rule of thumb to determine how widely they vary but if the DB on the failover system is in synch with the primary (i.e. you aren't seeing a bunch of synch errors in the logs) then you can be sure the SQLDMO backups of the UnityDB is going to produce the same data when restored regardless.

I'm not sure if that accounts for the entire difference between your backup sized - there could also be logging/transaction trunction configuration differences between your primary and failover or something similiar as well.