07-19-2013 05:20 PM
I wanted to see if someone knew this....
I have several Netapp volumes being backed up once a month, full once a month, and cumulative incrementals every night. The fulls complete just fine over the span of about a week, then the incrementals happen every night. Most incrementals behave as per normal, with only about 5 -10% of the size of the full being backed up, except for 2 volumes where the incrementals are the same size as the fulls. it also happens to be the 2 largest volumes, 5TB and 9TB respectively. all the jobs are identical so I can't imagine it'd be a something in the setup, and there is no way my company updates that much data daily. (Before you ask, I've checked all the culprits, AV - reporting SW ect. and they voles omly house cifs shares, so not DB or anything)
so I was just wondering if at a certain size NDMP just loses its ability to check the dump level?
thanks
07-19-2013 05:21 PM
ugh.... and is there a way to fix my spelling errors once ive published?
07-20-2013 03:53 AM
Whether a certain size NDMP loses the ability to check dump level, is a question to ask Netapp instead. But I wouldn't need it will, otherwise it could be a serious bug somewhere in the OnTap software.
What I can think of is how did you configure to backup the 2 affected volumes, did you use any special type of directives to backup (such as set type=???).
The only thing I can think of is if you backup a volume snapshot path which is not uncommon these days - snapshot path usually get changes/updates daily but the change should not be too excessive.
Best to let Netapp knows about this.
07-22-2013 02:40 AM
Your issue sounds very similar to the one from the following thread, see if it has the answer you have been looking for.
https://www.symantec.com/connect/forums/ndmp-incremental-backing-unchanged-data-ibm-sonas
Basically, starting from the 9th incremental, all further incrementals will only reference the 8th incremental, making each incremental larger by the day. (They become like cumulative incrementals, in NetBackup terms).
The solution is to have at least a full backup between every 9 NDMP incrementals. In practice, it is best to have weekly fulls with your daily incrementals, so that it "resets".
For spelling erros, just hunt the EDIT button down and click on it angrily.
07-22-2013 08:37 AM
RLeon, that is quite a write up on dump level backups, Thank you, I looked everywhere for something as succinctly written as that.
The fact is, I knew when I settled on monthly fulls that differential incremental was not an option for me, which is why I went with cumulative incrementals, with a shorter retention period (so as not to fill up my tapes.) The problem is that even a cumulative incrememtal on a 3 week old full backups shouldn't write the exact same size as the full, especially not on a volume used for cifs shares; and for the most part it doesn't. On 15 policies it does exactly as it should with only about 10 -15% usage. but on the two largest shares, immediately after a full backup the cumulative incremental blows out in size.
Watsons, I've looked around the netapp forums and I havent seen anything mentioned, but I'll keep checking to see if this has shown up in other netapp instances, I was more wondering if anyone has seen this within the netbackup community, I thought maybe it was a limitation within the policy engine. The jobs themselves are no different from the others, they were infact created by cloning from the first policy. and it's not like its ignoring the full backup,
07/19/2013 10:37:19 - Info ndmpagent (pid=19058) <NAS>: DUMP: Date of this level 1 dump: Fri Jul 19 10:37:13 2013.
07/19/2013 10:37:19 - Info ndmpagent (pid=19058) <NAS>: DUMP: Date of last level 0 dump: Tue Jul 2 23:42:58 2013.
It just calculates the level 1 dump as being the same huge size.
I might see how it goes after the next full and paste the first Cumulative Incremental results here.