Video Screencast Help

Accelerator backup of Windows Cluster systems

Created: 05 Sep 2013 • Updated: 06 Sep 2013 | 3 comments
Language Translations
Morten Seeberg's picture
+6 6 Votes
Login to vote

So you have a Windows clustered file server, and want to use Accelerator.....but what about Windows Change Journals and NetBackup Track files?

  • Windows Change Journals follow the file system, so what happens when it’s moved to the new node?
  • NetBackup Track files are put on the local file system (c:\Program Files….).

Did some trial-and-error and found the following solution, I have performed several tests and have not found anything wrong with it:

  1. Add all physical nodes to a policy which backs up C:\ and System State.
     
  2. Enable Change Journal in Host Properties for the client.
     
  3. Create a NetBackup Policy for the cluster file system.
    Attributes: Enable Accelerator, Target must be MSDP (or other supported)
    Client: Virtual hostname for the file system
    Backup Selection: T:\ (or whatever the file system is mounted as on the cluster nodes)
     
  4. Run a manual first backup of the file system with “Accelerator Forced Rescan” schedule.
    Verify the track log is generated on client in:
    C:\Program Files\VERITAS\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>\<backup selection>\track_journal.v?.dat”

    Verify change journal is enabled:
    fsutil usn queryjournal t:
     

  5. Create a directory on the shared file system drive:
    T:\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>
    Move the content of:
    C:\Program Files\VERITAS\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>\
    to
    T:\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>

    Then link to the shared path:
    mklink /D “C:\Program Files\VERITAS\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>” “T:\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>”

    Verify the link works using cd in CLI or explorer.

    Run an incremental backup and verify that it works:
    03-09-2013 16:14:38 - Info bpbkar(pid=5272) change journal enabled for <T:\>       
    03-09-2013 16:14:39 - Info bpbkar(pid=5272) using change journal data for <T:\>

     

  6. Failover the cluster service to next cluster node and perform the following actions:
    Create the directory structure in local file system:
    mkdir C:\Program Files\VERITAS\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\

    Then create the same link here:
    mklink /D “C:\Program Files\VERITAS\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>” “T:\NetBackup\track\<master server hostname>\<media server hostname>\<cluster node>\<policy name>”

    Verify the link works using cd in CLI or explorer.

    Open the cluster policy and close it again (the policy verification seems to sometimes contact the client and “let NBU client know that there is Change Journal enabled for this file system).
    Restart the “NetBackup Client Service” on the node (this is not always necessary but better to be safe than sorry J ).

    Run an incremental backup. First time it returns with this messages, I think its because Windows has lost track of the USN count when the file system was moved):
    03-09-2013 16:19:53 - Info bpbkar(pid=3676) change journal enabled for <T:\>       
    03-09-2013 16:19:53 - Info bpbkar(pid=3676) NOT using change journal data for <T:\>: unable to locate journal data

    Rerun the incremental and 2nd attempt should state OK:
    03-09-2013 16:27:37 - Info bpbkar(pid=4788) change journal enabled for <T:\>       
    03-09-2013 16:27:38 - Info bpbkar(pid=4788) using change journal data for <T:\>

    Repeat this section for each cluster node.
     

  7. Configure the master server alternate restore permissions. On the master server update the file(s):
    …\Veritas\NetBackup\db\altnames\<physical cluster node name>
    and insert the virtual cluster node name(s) on a separate line.

 

Results:

So what’s the point if it loses track after failover anyway?

I used 133.000 files, 34.000 folders, 23Gb data for the test.

 

“server1” active, first full backup already done, no real change to files.

03-09-2013 16:14:38 - Info bpbkar(pid=5272) change journal enabled for <T:\>       

03-09-2013 16:14:39 - Info bpbkar(pid=5272) using change journal data for <T:\>      

03-09-2013 16:15:04 - Info bpbkar(pid=5272) accelerator sent 70023680 bytes out of 249973760 bytes to server, optimization 72.0%

03-09-2013 16:15:04 - Info bptm(pid=32083) waited for full buffer 6 times, delayed 1988 times   

03-09-2013 16:15:13 - Info bptm(pid=32083) EXITING with status 0 <----------       

03-09-2013 16:15:13 - Info dkaarnbume01(pid=32083) StorageServer=PureDisk:dkaarnbume01; Report=PDDO Stats for (dkaarnbume01): scanned: 244142 KB, CR sent: 15348 KB, CR sent over FC: 0 KB, dedup: 93.7%

1:35 minutes, Full Accelerator support....

 

Failed over the file service to “server2”, and ran the incremental:

03-09-2013 16:19:53 - Info bpbkar(pid=3676) change journal enabled for <T:\>       

03-09-2013 16:19:53 - Info bpbkar(pid=3676) NOT using change journal data for <T:\>: unable to locate journal data

03-09-2013 16:20:57 - Info bpbkar(pid=3676) 5000 entries sent to bpdbm       

03-09-2013 16:21:12 - Info bpbkar(pid=3676) 10000 entries sent to bpdbm       

03-09-2013 16:21:32 - Info bpbkar(pid=3676) 15000 entries sent to bpdbm       

03-09-2013 16:22:24 - Info bpbkar(pid=3676) 20000 entries sent to bpdbm       

03-09-2013 16:22:42 - Info bpbkar(pid=3676) 25000 entries sent to bpdbm       

03-09-2013 16:23:07 - Info bpbkar(pid=3676) 30000 entries sent to bpdbm       

03-09-2013 16:23:28 - Info bpbkar(pid=3676) accelerator sent 188777472 bytes out of 366990336 bytes to server, optimization 48.6%

03-09-2013 16:23:28 - Info bptm(pid=529) waited for full buffer 233 times, delayed 12480 times   

03-09-2013 16:23:38 - Info bptm(pid=529) EXITING with status 0 <----------       

03-09-2013 16:23:39 - Info dkaarnbume01(pid=529) StorageServer=PureDisk:dkaarnbume01; Report=PDDO Stats for (dkaarnbume01): scanned: 358418 KB, CR sent: 20429 KB, CR sent over FC: 0 KB, dedup: 94.3%

4:51 minutes. Yes it was slower, but notice that it only scanned approx. 30.000 entries, I believe this is because of the shared NetBackup Track file.

 

Second incremental on “server2”:

03-09-2013 16:27:37 - Info bpbkar(pid=4788) change journal enabled for <T:\>       

03-09-2013 16:27:38 - Info bpbkar(pid=4788) using change journal data for <T:\>      

03-09-2013 16:28:01 - Info bpbkar(pid=4788) accelerator sent 70024704 bytes out of 249974784 bytes to server, optimization 72.0%

03-09-2013 16:28:01 - Info bptm(pid=1808) waited for full buffer 9 times, delayed 991 times   

03-09-2013 16:28:09 - Info bptm(pid=1808) EXITING with status 0 <----------       

03-09-2013 16:28:09 - Info dkaarnbume01(pid=1808) StorageServer=PureDisk:dkaarnbume01; Report=PDDO Stats for (dkaarnbume01): scanned: 244143 KB, CR sent: 15429 KB, CR sent over FC: 0 KB, dedup: 93.7%

1:32 minutes, So it’s already working normally again.

 

Ran an full rescan backup on “server2” as a reference, which shows what the backup time would have been without any accelerator working:

03-09-2013 16:29:45 - Info bpbkar(pid=5824) change journal enabled for <T:\>       

03-09-2013 16:29:45 - Info bpbkar(pid=5824) NOT using change journal data for <T:\>: checksum validation requested  

03-09-2013 16:30:17 - Info bpbkar(pid=5824) 5000 entries sent to bpdbm       

03-09-2013 16:30:31 - Info bpbkar(pid=5824) 10000 entries sent to bpdbm       

--cut--

03-09-2013 16:41:18 - Info bpbkar(pid=5824) 160000 entries sent to bpdbm       

03-09-2013 16:41:44 - Info bpbkar(pid=5824) 165000 entries sent to bpdbm       

03-09-2013 16:42:13 - Info bpbkar(pid=5824) accelerator sent 797236224 bytes out of 24888171520 bytes to server, optimization 96.8%

03-09-2013 16:42:14 - Info bptm(pid=4467) waited for full buffer 1318 times, delayed 41120 times   

03-09-2013 16:42:49 - Info bptm(pid=4467) EXITING with status 0 <----------       

03-09-2013 16:42:49 - Info dkaarnbume01(pid=4467) StorageServer=PureDisk:dkaarnbume01; Report=PDDO Stats for (dkaarnbume01): scanned: 24309036 KB, CR sent: 54489 KB, CR sent over FC: 0 KB, dedup: 99.8%

14:01 minutes, It scanned all entries and ran for much longer period, like a normal backup.

Comments 3 CommentsJump to latest comment

Sanjiv Kumar's picture

Great post...thanks.

0
Login to vote
Enrique Pereira Calvo's picture

Thanks. I thougth it should work, but it is very helpful to have someone that has tested it :-)

0
Login to vote
provnb's picture

Great, it works!

No more forced rescan ;-)

- ruud

0
Login to vote