EV NBU Agent, backup selection configuration, why ?

[FreKac2]

Hi all,

Created a post earlier today but it seem to be lost in space.

I'm primarely an EV guy so bare with me in case of any ignorance in regard to NBU.

But when reading the manual and trying the agent out there are a couple of things that don't exactly match how EV work.

Could be just the lack of scenarios in the manual or may not be applicable, but I would like to confirm/check a couple of things.

1. Why can't you backup the Directory DB in the same policy as partitions and index ?

Or why does the Best Practice part say that you shouldn't run a DirDB backup at the same time as a partition/index backup ?

It's just a database among the other database's so I fail to see the reason for this.

Also when doing archiving, any new mailboxes that will get enabled get new entries in the DirDB.

In case of "murphy" you could potentially have a discrepency/non-consistancy between the DirDB and e.g. vault stores.

E.g. new mailboxes enabled and archived, backup of VS and partitions, failure/"murphy", now recovered.

The mailboxes don't have any reference between mailbox and archive in the Dir DB because the crash happened after the VS and partitions where backed up but before the DirDB was backed up.

2. In the best practice part of the manual it states that the index backup should have a seperate policy, why ?

I mean you want the Vault Stores, Vault Store partitions and Index to be consistant with eachother, which as far as I know you can't "guarantee" with two seperate policies.

Sure it's not super critical to have a 100% consistancy between the index and vault stores,  but it will mean that EV will need to re-index/update potentially quite a lot of information after a recovery. So again why the recommendation of a seperate policy ?

Thanks

Fredrik

[RiaanBadenhorst]

Hi,

Question / Point 1

NetBackup needs to run SQL and File System backups to protect the different components in EV, and you cannot combine these into 1 policy. So that is the reason I would say you split the DB's and the Index/VaultStores

Question / Point 2

If you're backing up the indexes they'll be in read-only mode, which means that you wont be able to add anything to the archive even if you try. Similarly, if you backup the vault stores, they'll also be in backup mode for the duration, so once again, no new content can be added to the archive. So basically when either component is in the read-only/backup mode, no content can be added, and no inconsistency can occur.

Do you agree?

[FreKac2]

Not really, sorry ;)

1. Since the Directory DB is the only one that can't be in the same policy, which mean that the MonitoringDB and the Vault Store DB can be part of the same policy. If you select open partitions the VS DB is automaticly backed up as well. Which mean both files and DB's in the same policy. So then why does the agent allow all except the Directory DB to part of one policy ?

2. Yes the indexes will be put into backupmode then NBU will backup the data, just as it will be done with the VS partitions. But, correct me if I'm wrong, when you launch the first policy, that policy will put EV into backupmode it will backup the VS and the VS DB. Once the job is done it will clear the backupmode but you can't be sure that the Index policy has started, right.

E.g. just for the arguments sake, lets say you go straight to tape and all tape drives are allocated when the indexjob starts.

So I'm not looking at the idea of something gets added during either of backup jobs but the idea of one of the backups being out of synch. Especially the Directory DB as you will have information being added to it during archiving e.g. new archives from "automaticly enable users" settings in EV. The main question in regard to indexing is why the best practice is to have a seperate policy for it ?

But of course if the indexbackup doesn't happen right after the VS backup and you have a crash in between you'll have to re-index, potentially quite a lot of information. So not an unrecoverable situation but still.

/Fredrik