cancel
Showing results for 
Search instead for 
Did you mean: 

Incrementals do full backup after 6.0 MP6 upgrade

ayoung1969
Level 3
Hi,
We performed an upgrade from NBU6.0 MP4 to NBU6.0 MP6 yesterday.
 
When our usual incremental backups ran last night they all backed up the full amount of data on the server (ie effectively a full backup).  Subsequent backups on a server performed incrementals as expected (provided the first backup after the upgrade had completed).
 
It looks like the upgrade to MP6 caused the NBU database to lose the records of what was previously backed up and so forced it to back everything up again.
 
Has anyone else seen this before ?
 
21 REPLIES 21

PatrikJ
Level 3
Certified
Hi all,

I got the same problem after upgrading yesterday. In my case, not all backups where performing full backups. Some behaved as expected. Does anyone have any clue for this behavior?

Rgds

Omar_Villa
Level 6
Employee
sounds like a bug, have anyone of you opened a case for Symantec?

ayoung1969
Level 3
Yes, we logged a case and at the moment we've had no response other than the fact that they can see from the logs that the backup is running an incremental as requested by the schedule.
As yet there's no explanation of why each of the incrementals backed up all of the data.
 
As you say, it sounds like a bug.

Dan_Lynch
Level 3
I'm having the same exact issue - Did symantec ever come back with anything useful?
I hate upgrading the night after full backups complete...It's going to be a long week, I get the feeling.
 

ayoung1969
Level 3
It looks like Symantec do have an issue with this.
We got a reply back from the engineer dealing with our case and the short version is (and this is paraphrasing them so forgive me if it's not 100% correct but you'll get the idea) :
Prior to NBU 6.0 MP6 a single STREAMS file for each client was created.
After the upgrade to MP6  they create a STREAMS<policy name> file.
 
Since the file contains info such as last backup time of the relevant files it's used to determine what needs to be backed up and, because the first STREAMS<policy name> file created after the upgrade doesn't contain any historical info (remember the name has been changed) it treats the next backup as a full.
The same thing would happen in earlier versions of NBU if you were to delete the STREAMS file.
 
It's a safety feature that's done by design,  I think what Symantec need to look at is some way of getting the historical info copied into the new file.
It's not a problem if you do full backups but watch out for capacity issues with VTLs or tape pools if you're doing an unexpected full backup (full in terms of volume written).

Dan_Lynch
Level 3
Thanks a lot for the update!
I had to move some of my dsu jobs to tape but I still missed a couple and narrowly avoided a big issue.  I really wish symantec would warn customers of this...

Stumpr2
Level 6
It sounds similiar to the problem they had with TIR on the client. If the TIR folder was deleted or missing (for instance  the D:\ drive) then the backup would include everything on the D:\ drive even though it was supposed to be an incremental backup.

Dan_Lynch
Level 3
Good point - I've had that happen too a while back...I removed TIR from all policies that I could after that happened. 

Stumpr2
Level 6


ayoung1969 wrote:
 
Prior to NBU 6.0 MP6 a single STREAMS file for each client was created.
After the upgrade to MP6  they create a STREAMS <policy name> file.


Is this covered in the README file for MP6?

ayoung1969
Level 3
I don't believe it is in the README but we might have missed it.
 
The engineer says that there's a "TN" about to be released concerning this.
Apparently they're also working on a fix at the moment.

Dan_Lynch
Level 3
Here's what I got back from support -
-----
This is a known issue and it is necessary to run a complete full backup for the affected policies (manual or scheduled).  Once the full backup has completed, the incrementals will function as normal.
-----
 
This is completely unacceptable to us - a few of our fulls take over 24 hours and we can't run these kinds of backups during the day.  Does anyone know how to manipulate the STREAMS files?  I have a vague idea but wonder if anyone has a better one?
 

Andy_Welburn
Level 6


@ayoung1969 wrote:
Prior to NBU 6.0 MP6 a single STREAMS file for each client was created.
After the upgrade to MP6  they create a STREAMS<policy name> file.


Did they change this back again?
We are running 6.5.1 (from 5.1MP6 some time ago) & we only have a single STREAMS per client

PatrikJ
Level 3
Certified
My guess is that in 6.5.2, they will have the STREAMS<policy name> files.
Which will demand a full backup after upgrade?

IF my guess is true, hopefully Symantec has implemented some kind of migration of the files during the upgrade.

Maybe someone with inside info can give us a clue?

Regards
Patrik

------------------------------------------------------------------------------------------

@ayoung1969 wrote:
Prior to NBU 6.0 MP6 a single STREAMS file for each client was created.
After the upgrade to MP6  they create a STREAMS<policy name> file.


            Did they change this back again?
            We are running 6.5.1 (from 5.1MP6 some time ago) & we only have a single STREAMS per client

 
            Regards, Andy.

------------------------------------------------------------------------------------------

Stumpr2
Level 6
Sometimes symantec employees monitor threads. I'll see if I can rouse one up. Smiley Wink

Dan_Lynch
Level 3
Here's what I got from my open case...Better late than, well, nevermind this still stinks...It sounds kludgy.
 
I was always of the opinion that "new features" shouldn't be included in management/service packs.
Symantec below:
------------
Issue: After NB_60_6_M patch is applied the next backup creates a new STREAMS file named STREAMS<name_of_policy>. With this new feature if the next backup that is about to run is an incremental (INCR) backup, it will run as a FULL backup regardless if it is a regularly-scheduled or manually initiated backup. This is not a FULL schedule but rather defined as a FULL backup: A full backup backs up all files specified in the backup selections list for the policy, regardless of when the files were last modified or backed up.
 
 
Work-around:
Below are two work-around options that are available to you.
1. After a successful upgrade to NB_60_6_M, manually execute a FULL backup for all policies that include "Allow multiple data streams" for all clients.
This generates a new STREAMS file per client, per policy, and sets the last successful backup time.
This is recommended to ensure that pre-processing is valid, new STREAMS files are generated, and FULL backups complete successfully.
2. After a successful upgrade to NB_60_6_M but before running any backups, manually copy and rename the existing STREAMS file.
For example: The STREAMS file contains the last record of a successful backup for each SCHEDULE in the policy for each data stream.
T 0 0
1 1206547142 TEST FULL 0,0,604800 0 0 C:\temp
2 1206547144 TEST CINCR 0,0,604800 0 0 C:\temp
1 1206547143 TEST_2 FULL 0,0,604800 892691764 0 C:\temp
2 1206547145 TEST_2 CINCR 0,0,604800 0 0 C:\temp
1 1206547154 tesT_3 FULL 0,0,604800 0 0 C:\temp
2 1206547155 tesT_3 CINCR 0,0,604800 0 0 C:\temp
In the above example, three policies exist TEST, TEST_2 and tesT_3 each having two schedules CINCR and FULL with two streams per schedule.
The work-around is to create a copy of the original STREAMS file before starting a backup and rename it to the new format: STREAMS<policy_name>.
Note: The policy name is case sensitive. Rename the file to STREAMSTEST for a policy named TEST.
For example: The renamed file is: STREAMSTEST
T 0 0
1 1206547142 TEST FULL 0,0,604800 0 0 C:\temp
2 1206547144 TEST CINCR 0,0,604800 0 0 C:\temp
The STREAMSTEST file now contains stream data for the client for the policy TEST.
Note: For a successful work-around; all streams that are not related to the policy TEST must be removed and contained in a separate STREAMS<policy_name> file.
Using the same example, three STREAMS files are needed.
One STREAMS file is needed for STREAMSTEST, one for STREAMSTEST_2 and the third is needed for STREAMStesT_3. Each new streams file contains the stream records for the corresponding policy name.
For example, for policy tesT_3 the streams file contains only two stream records. Notice that the streams for policies TEST and TEST_2 have been removed.
T 0 0
1 1206547154 tesT_3 FULL 0,0,604800 0 0 C:\temp
2 1206547155 tesT_3 CINCR 0,0,604800 0 0 C:\temp
 

Tyler_Carter
Not applicable
Employee
Some additional detail from Product Management on this...
This was expected behavior after a 6.0 MP4 to 6.0 MP6 upgrade.  The reason is because of some changes we made to the job handling that necessitated redoing the backups as fulls the first time.  There is a tech note in process and the release notes are being updated to call this out.
 
Also, there will be a similar change coming in 6.5.2 which will again cause the incremental backups to run as fulls the first time.  We will need to make sure it is clearly called out in the release notes to avoid confusion.
 
In both these cases, the underlying changes that caused this behavior, were solving bigger issues, so while this is a one time inconvenience for our customers, it addresses longer term , recurring problems.

Andy_Welburn
Level 6


@PatrikJ wrote:
My guess is that in 6.5.2, they will have the STREAMS files.
Which will demand a full backup after upgrade?



Do you know this weeks upcoming lottery numbers too!! Smiley Wink

PatrikJ
Level 3
Certified


@Andy Welburn wrote:


@PatrikJ wrote:
My guess is that in 6.5.2, they will have the STREAMS files.
Which will demand a full backup after upgrade?



Do you know this weeks upcoming lottery numbers too!! Smiley Wink



8, 13, 16, 21, 24, 28, 32? Smiley Wink

Good Luck!

Patrik

Stefan_Schmid_2
Level 4
DOCUMENTATION: After applying the NetBackup 6.0 MP6 maintenance pack,
the first incremental backup run for each multistreamed policy on each client will run
as if they were full backups.


http://seer.entsupport.symantec.com/docs/301465.htm