This post is more than 5 years old
5 Posts
0
5385
Block Based incremental Backup allways changes into full
Hi
I am a bit confused: whenever an incremental backup of our fileserver data disks is run (networker 8.2.0.5 with datadomain 5.5) it always turns into a full backup.
In the logs I sometimes see following message: 101302:save: A block backup chain link conflict is identified due to time stamps mismatch for volume 'D:\'. Falling back to level full.
I scheduled a full backup for this weekend so I hope this might fix the problem...
in the administration guide (p 542) I read the following =>
When you perform an incremental backup to a Data Domain device, you perform the backup as a virtual full
backup. However, the type of the backup that you have performed is displayed as full.
Anyone else ever had this problem (I saw some other posts regarding this problem but I guess they never got solved)
grtz
Tim
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