2010-05-20 01:15 PM - edited 2015-12-18 01:34 AM
I'm working with a client running SMMOSS 5.0. Local backups are working. We are now taking steps to replicate to another site for DR purposes. It was our understanding that this should involve:
1) set up dst vols, restrict vols, do "snapmirror initialize" - on database, logs and snapInfo volumes (and did not create snapmirror schedules on any of them)
2) then adding a check in the box in SMMOSS backup plan option: "Update SnapMirror after operation"
We did these two things and toward the end of the next "SMMOSS Backup Plan" we ran the database and log volumes were snapmirror updated ... but not the snapInfo volume.
Shouldn't all three volumes have been updated?
2010-05-21 02:06 AM
I can't find any written proof, but normally snapinfo volume doesn't get automatically replicated together with data or logs volumes. You can either create own schedule for it, or the TR-3819 mentions this:
"For smaller production hosts, the SnapInfo directory can share a volume with the transaction logs."
2010-05-21 09:55 AM
Thanks. Gee, I'd downlaoded and reviewed 4 other SMMOSS TR's but never saw TR-3819 ... and it's the most recent ... but it's on the second page of results if you search for "sharepoint" TR's (you have to click "Next"). I'll look at that one.
A more basic but related question ... Isn't the snapInfo directory needed at the DR site to perform a DR recovery operation. I'm not a SM-MOSS or SM-SQL expert but I thought it included important info needed to do a recovery/restore. And ... if it is needed, and it's in a separate volume (which our is), what kind of schedule would I set up to replicate it. We do a daily SMMOSS backup which now also triggers snapMirrors of DBs and Logs. If I schedule the snapInfo volume to snapMirror update a few few minutes after the SM-MOSS backup completes will that work? will be be consistent with the DBs/Logs?
2010-05-26 11:47 AM
I just got back on-site to look into this and found that now, a few days later, the SnapInfo volume is indeed now being SnapMirror updated at the same time as the data and log vols/LUNs by SMMOSS. Not sure why it didn't seem to update the first time we backed up with SMMOSS but it's picked now and all three vols/LUNs are SnapMirror updating.