cancel
Showing results for 
Search instead for 
Did you mean: 

VM backup accelerator not work if policy name changed

Ken_Chan1
Level 3

Dear Sirs,

I have 5 backup policies to handle VM backup to control it started in different days.

(eg. Server1 is run on Mon, Server2 is run on Tue, Server3 is run in Wed, etc ...)

Just found the VM backup accelerator will not work if I move Server2 from Tue policy to Mon policy. The backup job will show "There is no complete backup image match with track journal, a regular full backup will be performed ". Then it will take more time to backup.

Any solution to fix the problem ? Due to I have over 400 VM clients need to re-arrange the backup days.

Many thanks.

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

It appears that the VMware state files are saved on the master server under the following directory <INSTALLPATH>\NetBackup\db\snapshot\vm\<vmname> or /usr/openv/netbackup/db/snapshot/vm/<vmname>
Where vmname is the name used during the backup. 

During the backup, the state files are located on the backup host in the online_util\fi_cntl directory, but are removed once the backup completes.

It also appears that the NBU policy is contined within the state files saved - which is annoying but understandable as a different backup policy may not backup the same data (e.g. exclude data drives or not).

View solution in original post

12 REPLIES 12

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

@Ken_Chan1 

This is to be expected if you check the track log folder and see what the directory structure looks like. 
See this TN : https://www.veritas.com/content/support/en_US/article.100038114.html

A new folder will by created for NEW_POLICY to start building a track log for this policy.

So, before you create a new policy, you may want to copy contents of: 
<install_dir>\NetBackup\track\MASTER\STORAGE1\CLIENT\POLICY1 to NEW_POLICY

@Marianne,

I can't found the "track" folder in Master server and also the VM clients (No backup agent installed in VM clients).

 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

@Ken_Chan1 

As per the TN: track logs are created on the NetBackup client systems. 

For VMware backups, the 'backup host' acts as client. In most cases, this will be the media server.

Ken_Chan1
Level 3

@Marianne,

The Master server is the VM backup host, and also check the Media sever which control the storage unit.

No such folder found ~

Ever done a restore from these VM Accelerator bacups? You can't resotre without a track log.

@Jim_MD,

Restore is no problem, thanks.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

@Ken_Chan1 

Please check on of your VMware policies where Accelerator is selected. 
In the VMware tab, please check what is selected as 'Backup Host'.

The accelerator track log will be on this host. 

 

@Marianne,

Yes, it shown the master server as VM backup host.

But strange that can't find the such folder in master server ~~

According this

 How to calculate the NetBackup Accelerator track log size

https://www.veritas.com/support/en_US/article.100045746

"VMware backups do not use a track log, instead state files are created on the Backup Host. The state file stores information about each extent of data on a virtual disk:"   This was published this year ...I assume it applies to old versions and I haven't a clue what state files are.   This makes sense as VMware Accel' uses CBT and not what files have chnaged.

It appears that the VMware state files are saved on the master server under the following directory <INSTALLPATH>\NetBackup\db\snapshot\vm\<vmname> or /usr/openv/netbackup/db/snapshot/vm/<vmname>
Where vmname is the name used during the backup. 

During the backup, the state files are located on the backup host in the online_util\fi_cntl directory, but are removed once the backup completes.

It also appears that the NBU policy is contined within the state files saved - which is annoying but understandable as a different backup policy may not backup the same data (e.g. exclude data drives or not).

Hi All,

That's mean it is unavoidable if change to another policy ?

Yes quite so. Now please note I'm not endorsing what I'm about to suggest and this is certainly not to be taken as a supported procedure, but something that appears to have worked for me in a test environment.

Note for the VMware backup I am simply putting the VM into a new policy and not in anyway altering what is being backed up (i.e. all VMDK's are included).

For a client I was testing - finance1 - I went to the directory <instll_path>\NetBackup\db\snapshot\vm\finance1 and noted the set of files from last backup:
bpfis.fim.finance1_1568681516.1.0
bpfis.fim.finance1_1568681516.1.0.changeid.xml
bpfis.fim.finance1_1568681516.1.0.NBU_DATA.xml
bpfis.fim.finance1_1568681516.1.0.NBU_DATA.xml.BID
bpfis.fim.finance1_1568681516.1.0.VM_ObjInfoXML.xml
bpfis.fim.finance1_1568681516.1.0_nba5240.example.com.extent

I manually edited the two highlighted files above and replaced every occurrance of the old policy name with the new policy name (there are about 7 ocurrances in the first and 1 in the second). When I ran the next backup using the new policy, the accelerator picked up an existing track log and behaved accordingly. 

Now, I have not tested restoring from this backup, and I use this at your own risk - it does save some time for the initial backup using the new policy, but if you are using an MSDP pool, you are only saving time as the data will dedupe to a high amount (the entire VM has to be read, but most can be "ignored" as it already exists on the target MSDP.