I opened a ticke @ EMC and they provided the solution:
As I said we saw that, after the backupjob, the indexes were saved under the entry of the physical node of the cluster, so the next time we ran the backup of the virtual node networker did not see the index and performed a full again.
We put the command "save -c name_of_client" in the backup command field of the Apps & Modules tab of the virtual client and this forces the index to be written in the right place.
Now we see that the job does synt_fulls as it should :-)
Found this information bellow, support may validate it.
When using VFS , while DDBoost is the target device, BBB incremental backup is automatically promoted to synthetic-full. There is no need to enable it on group properties. This is by-design, and we cannot disable it.
The way BBB works:
All the BBB incremental backups to DD shall be performed at Virtual full.
If the level is incr, it would be automatically promoted to Virtual full when the target device is DD. So it will not be “incr+synthetic full”. Instead incr would be promoted to “Virtual full”.
The BBB will check last incr, if it failed, BBB would run a full backup.
If the last incr backup succeed, BBB would check last incr long SSID.
Check the last incr volume id.
Check if the last BBB reach limitation 38.
Check the time stamp for previous backup. The backup server request a backup start time for last incr backup and last backup will return a backup start time.
Yes I found that info too, I first thought this was the answer but the problem is that the backup of the disks on the clustered machines don't do a synthetic full but a "real" full , which takes a little longer ;-)
In the same policy we have some other, non-clustered, fileservers and indeed they do a synth_full instead of the incremental which is in the schedule...
The schedule is inc every day / inc+synth full every saturday / first sat of month real full / nothing on sunday, so yes
it's a VSF.
Time is synced ok I checked (we use the same ntp everywhere).
In the meantime we found out that after each backup, networker writes the indexes of the backup under the folder of the "physical nodes" instead of the virtual nodes (where the disks are).
So every time we do a backup I guess networker doesn't find the index and performs a full...
th12
5 Posts
0
February 16th, 2015 00:00
I opened a ticke @ EMC and they provided the solution:
As I said we saw that, after the backupjob, the indexes were saved under the entry of the physical node of the cluster, so the next time we ran the backup of the virtual node networker did not see the index and performed a full again.
We put the command "save -c name_of_client" in the backup command field of the Apps & Modules tab of the virtual client and this forces the index to be written in the right place.
Now we see that the job does synt_fulls as it should :-)
Tim
th12
5 Posts
0
January 23rd, 2015 07:00
I failed to mention that the client is a four node fileserver cluster (win 2012 R2).
In the admin guide it states explicitly that full's on shared volumes are supported =>
"Full backup of Windows Server 2012 Cluster Shared Volumes on File Servers and Windows Clusters"
it does not say anything on incremantel backups...
LilianaW
40 Posts
0
January 29th, 2015 03:00
Hello Tim,
Is this I Virtual Synthetic Backup (VSF) ?
Can you check to make sure that the time is synced between all the players ? ( the DD , storage nodes and server)
The problem need to be narrowed, reason cannot be found only from the error received.
There are few timestamps involved in the BBB backup kept by mmdb and writer tracker and they need to be checked.
I would suggest to open a case with support for further troubleshooting.
Regards,
--Liliana
LilianaW
40 Posts
1
January 29th, 2015 06:00
Hello Tim,
Found this information bellow, support may validate it.
When using VFS , while DDBoost is the target device, BBB incremental backup is automatically promoted to synthetic-full. There is no need to enable it on group properties. This is by-design, and we cannot disable it.
The way BBB works:
So it will not be “incr+synthetic full”. Instead incr would be promoted to “Virtual full”.
Regards,
--Liliana
th12
5 Posts
0
January 29th, 2015 06:00
hey Liliana
Yes I found that info too, I first thought this was the answer but the problem is that the backup of the disks on the clustered machines don't do a synthetic full but a "real" full , which takes a little longer ;-)
In the same policy we have some other, non-clustered, fileservers and indeed they do a synth_full instead of the incremental which is in the schedule...
Regards
Tim
th12
5 Posts
0
January 29th, 2015 06:00
Hi Liliana,
The schedule is inc every day / inc+synth full every saturday / first sat of month real full / nothing on sunday, so yes
it's a VSF.
Time is synced ok I checked (we use the same ntp everywhere).
In the meantime we found out that after each backup, networker writes the indexes of the backup under the folder of the "physical nodes" instead of the virtual nodes (where the disks are).
So every time we do a backup I guess networker doesn't find the index and performs a full...
I opened a ticket @ EMC support
kind regards
Tim