Forum Discussion

rsamora's avatar
rsamora
Level 5
12 years ago
Solved

Preferred Method for Cluster Backups

Howdy kids,


I found a tech note (TECH204072) that suggested, for a Microsoft cluster, create a policy for each node listing the local drives.  Create another policy for the virtual server listing all of the shared drives. 

I'm concerned that if someone adds another drive to the cluster, without ALL_LOCAL_DRIVES being used, I would never backup the data on that new drive.  Today, I backup only the physical nodes with ALL_LOCAL_DRIVES on the backup selections tab.  My thoughts are that no matter which node is hosting the shared drives, I will get the data on tape through the physical node backups. 

I only promise my customers data restoration, not full system recovery.  If the cluster crashed, the server dudes would have to rebuild the cluster, install any applications that are needed, and then I restore data.  So my physical node/ALL_LOCAL_DRIVES deal works for me.  That seems to be the best solution but after reading the tech note and running a couple of google searches, I'm wondering if I might be missing some critical data by not backing up the virtual node by the virtual node name.

What's everyone else doing?

Thanks,
Randy

  • What I recommend, which is what we use here in the company, is to create two policies as follows:
     

    1 - Shadow Component or System State:

    • Insert as client the nodes in the cluster (Physical Server)

    2 - Backup data from shared drives:

    • Insert as client the virtual name of the cluster and point to the shared disks.


    The local disks can also be made in the first policy, but only recommend doing if you have data, since  the system applications does not recover through normal backup windows, only through specific policies like BMR or, if VM, through the comlpete recovery of VMDK.

    I have done well here in the company and never had problems. All Microsoft cluster we do here, we backup the disks drives or folders we want to backup and do another policy to backup of Shadow Component (System State).

6 Replies

  • Taking shared disk backup through physical nodes is not so good as you need to determine  on which node services ran at backup time and initiate restore from backups of online node. In addition, you can not configure incremental backups in this design.

    I highly recommend you to configure backups of shared disks using virtual name. To avoid missing new local disks, use ALL_LOCAL_DRIVES directive in physical node backup. You should exclude shared disks from physical node backups using Exclude List.

  • Thanks for the input, you've both stated similar solutions and Symantec recommends the same configuration you've suggested.  But it doesn't address the concern I have about someone adding a new shared drive without my knowledge.  The shared drives are listed specifically so if a new drive is introduced, it won't get backed up.  I guess this is where the server guys have to take some responsibility and inform me if they want the new data backed up.

  • What I recommend, which is what we use here in the company, is to create two policies as follows:
     

    1 - Shadow Component or System State:

    • Insert as client the nodes in the cluster (Physical Server)

    2 - Backup data from shared drives:

    • Insert as client the virtual name of the cluster and point to the shared disks.


    The local disks can also be made in the first policy, but only recommend doing if you have data, since  the system applications does not recover through normal backup windows, only through specific policies like BMR or, if VM, through the comlpete recovery of VMDK.

    I have done well here in the company and never had problems. All Microsoft cluster we do here, we backup the disks drives or folders we want to backup and do another policy to backup of Shadow Component (System State).

  • About adding new drives, here we require is requested by the head of the service, so any change in service or server that should also be in the backup routine should be given, otherwise it is not the responsibility of backup team if the same does not happen in the desired way.

    So I suggest that this routine is followed and that all change is informed to your team, so you can update the backup routines like requested.

  • Thiago, thank you.  I agree, at some point, the other departments have to accept responsiblity.  We have a strict change control system here and if someone wants to bypass the system, then it falls on them if the data doesn't get backed up.

    Thank you all for you input, it reaffirms Symantec's recommendation.  I was overthinking the issue by taking on too much of the responsibility.