We're planning to move to an Exchange 2013 DAG from our current Exchange 2010 CAS/Mailbox server setup. We're using NBU 188.8.131.52 with GRT to backup our Exchange 2010 environment; it's working great.
I see from this forum post https://www-secure.symantec.com/connect/forums/exchange-2013-and-grt that as of NBU 184.108.40.206 and up, Exchange 2013 is supported with GRT (allowing for single-item restores).
My question is, has anyone been able to restore from an Exchange 2010 GRT backup into an Exchange 2013 (will also be GRT-based) environment? I thought I would ask here before contacting support.
Thanks in advance,
I doubt whether this would work, because MS will very likely have introduced significant schema changes to the MailStore databases across major versions of MS Exchange. By all means test, and post back, but I wouldn't test it in production.
FYI - the DB SCL was updated a few days ago to state the v220.127.116.11 now supports MS Exchange 2013 CU7.
Exactly what service pack and/or roll-up are your two MS Exchange servers running?
Here's a thing... I believe (but anyone else please feel fre to correct/advise)... that even sometimes going from for example MS Exchange 2010 SPx to SPy will mean that one won't be able to restore any of the prior backups taken (whilst MS Exchange was at 2013 SPx) back in to MS Exchange which is now 2013 SPy - this is just an example, and I don't know this for sure.
What is clear, is that if this is true, then this is NOT a NetBackup issue, as all backup products will have this problem - because it is to do with the way that the MS Mailstore databases are structured - i.e. the database schemas, and the schema changes that MS may, or may not, implement from version to version of MS Exchange Server. The only way to confirm this for sure, would be to read the release notes for MS Exchange, and see if MS make clear statements regarding version to version inter-operability.
This whole situation kind of makes me want to edit the keyword in MS Exchange backup policies to capture the versions of both NetBackup Client and MS Exchange Server - so that it is possible to (at a later time) track which backups came from whichever versions, e.g. use a keyword in the backup policies:
...where XXXX could the the NetBackup verson, and YYYY could be the MS Exchange version, e.g.
Are there any NetBackup MS Exchange gurus who can comment on this?
Yesterday was fun with searching. It turns out that yes, as of NBU 18.104.22.168, GRT is supported with Exchange 2013. However, we'll probably upgrade right to the most recent GA, 7.6.1.
We're running CU7 (not the failed experiment which was CU8 ha ha) on Exchange 2010 SP3.
I see your points about the changes in schema, etc, but man! It was a pain for us to go from Exchange 2003 to Exchange 2010 as they were totally incompatible in terms of restores. But it was a huge jump so I kinda get that. I'm hoping the move from 2010 to 2013 isn't so large...
Yes, any Exchange gurus please hop in.
The NetBackup Compatibility Database SCL was re-issued four days ago, on Feb 24th:
Ok - you are on MS Exchange 2010 SP3 CU7.
If you are planning to go to MS Exchange 2013 CU7...
FYI - GRT support for MS Exchange 2013 began with NetBackup v22.214.171.124 - but... MS Exchange 2013 CU7 is only supported from NetBackup v126.96.36.199.
N.B. Because of the slight divergence between NetBackup v188.8.131.52 and NetBackup v7.6.1 - personally, I would definitely carefully double check with Symantec Support whether both GRT and MS Exchange 2013 CU7 are definitely actually supported with NetBackup v7.6.1 - as it's not clear to me. Please post your findings here.
LOL thanks for your posting! I did get this reply from support also on the 2nd:
In the scenario you described, the answer for GRT items is yes, but for an entire database, no. So you can restore emails, etc, individually to Exchange 2013 that were taken successfully with GRT in Exchange 2010. But restoring an entire Exchange 2010 database to Exchange 2013 won't work.
Just fyi, I also saw your forum post out there, and to answer the compatibility questions that I saw, 184.108.40.206 was released today, and it supports Exchange 2013 with CU7. It is on parity with 220.127.116.11. 7.6.1 was not; it was 18.104.22.168.
I guess I'll see sometime next week...! ;)
Cool. Glad it's doing what it's supposed to do.
Can I be cheeky and ask for more detail re versions...
1) Source: exact version details of client that was used to originally take the backup, O/S and patch level, MS Exchange version and patch level, NetBackup Client version?
2) Restore data mover (e.g. master/media or media): exact O/S and patch level, and NetBackup Server version?
3) Target: Exact O/S verison and patch level, exact version of MS Exchange and patch level, and NetBackup Client version being restored to?
Not being fussy - just curious to know exactly what has been proven to work (but without going into super detail about topology).
|Windows 2008 R2 Datacenter, SP1 in vSphere 4 environment||Exchange Server 2010, SP3||NetBackup 22.214.171.124|
|x64 with 32GB RAM||Update Rollup 7|
|Client for NFS installed||3 configured: 1 CAS w/2 mailbox servers|
|Critical and security Windows Updates|
|Master and/or Media Server||both|
|OS / Patch level||OEL 5.10 (uek): 2.6.32-400.36.13.el5uek|
|Hardware||PowerEdge R620, 16GB RAM|
126.96.36.199* -- *used to take backup
188.8.131.52** -- **used to restore
|Method||GRT from local RAID 5 disk|
|Windows Server 2012 R2 Datacenter in vSphere 5 environment||Exchange Server 2013, SP1||NetBackup 184.108.40.206|
|x64 with 16GB RAM||DAG: 2 servers|
My testing (NOTE: all was done with images created with GRT and were still on disk):
I hope this is what you were looking for! (Unfortunately I'm not out of the woods yet - we have 2 mailboxes in one of the DBs in the 2013 DAG environment but I can only see one. :( Working with support on it now.)
Turns out that if a mailbox is "Hidden from address book" GRT backups will neither see or restore it. One of those little "gotchas" that's good to be aware of. The tech I spoke with believes that a hidden mailbox would be available in a database-centric backup (not GRT).