Read only mode: always really required?

[Rob_Vollum]

Everything I read talks about the requirement of putting EV into read only mode before doing EV backups. I can see the point in places where archiving can happen at any time. I'd like to know if people think it's required in my case, though.

Users are not allowed to manually archive. Users can't delete. And users can't restore from the vault. Basically their mail is managed for them, period, based on desired policies. What happens to their mail, shortcuts, etc, is all done through EV tasks.

Given that, why take any time at all stopping and starting services across my 5 EV servers to put them into RO mode? Why not just run my tasks (archive, expiry, etc), and then start backups when that window is done?

Thanks for your opinions,

Rob

[Steve_C_Blair]

Hi Rob,

Your question is one that others have asked before, but I am not sure anyone's ever posted something in public ;0)

Sure, you can do as you propose and there is no reason not to, except:

1) if you have a HW crash, anything being/ready to/for archiving could be lost

2) if you had a HW crash, and the Index Volumes, SQL were out of sync, it gets painful to rebuild

3) if you had a "9.11" incident, you have little safety net.

Now we're not going to "smack your hand" if you do as you propose, but you have to accept a certain amount of responsibility, nee: Risk by doing so.

At least, make absolutely sure R/O is on your main Vault Site server where your Index and Directory DB are located please!

[MichelZ]

Also. have a look at the "Backup Whitepaper":

http://www.symantec.com/content/en/us/enterprise/media/stn/pdfs/Articles/best_practice_for_ev_backup...

Cheers

Michel

[Rob_Vollum]

Hi - thanks for your thoughts on this... I appreciate it. I'm not entirely sure that I understand your comments on the exposure that I face, however.

I am doing backups on a daily basis, and "soon" there will be a full, replicated, DR site, so I'm covered there. We're not tempting fate by skimping on backups.

So regarding not setting EV into read only mode during backups, what I'm not seeing is this: if my users can't do anything to manually archive/restore/delete items from EV, then how can the things you mention in your 3 crash scenarios happen? Nothing should be archiving, and nothing should be changing the SQL databases or indexes outside of the batch window that does archiving (etc) each night. I don't see how RO mode during backup protects me from anything, in my situation.

Thanks for helping me understand this - I want to do the right thing and I'm not trying to be lazy here. To me, it seems that not allowing users to do anything manually is effectively the same thing as read only mode. I apologize if I'm missing something obvious here... (I definitely see the point of RO mode if users can archive things, restore, delete, etc).

Regards,

Rob

[Steve_C_Blair]

Hi Rob,

The points you've covered in my reply are what I meant by limiting your exposure. That's good news!

During RO mode only a few things end-users can't do, most customers do an internal FAQ to help set expectations for they ca/can not do during these hours.

[kazakh_cowboy]

As always, you guys are very helpful. Doe's putting EV into "read only" mode still allow users to access their archived mail. I want to copy the vault store data overnight  to a new location but still want users to be able to read their archived mail during this period

[Liam_Finn1]

Yes they still have access when in Read Only mode it just means nothing new is added

[JonD]

Anyone know if VSFW snap backups require putting EV in RO mode ?   We traditionally did not pause exchange so i would guess not but have not been able to find a symantec practice.

regards,
      Jon D.

[MichelZ]

You could copy your vault store data with robocopy at any time with no need for read only mode. When you are finished, enable read only mode, and let robocopy copy only the delta data which had gathered. This way, you will need very little time in read only mode. Cheers Michel