cancel
Showing results for 
Search instead for 
Did you mean: 

One volume of a fileserver will not make synthetic full

someoldman
Level 3

I have a decently large Windows fileserver I am trying to back up.  Perhaps 24 tb total, but broken down into 4 main data volumes.   2 volumes are approximately 7 tb each, and the other two are aproximately 5 tb each.    

All of these volumes will do incremental backups without issue.    All will do standard full backups without issue other than taking an incredibly long time to full backup.   And 3 of the 4 of these volumes will consistently successfully create synthetic full backups.   However, there is one volume  or drive that consistently throws a 671 error when trying to do a synthetic full. 

I have each of these volumes in their own policy.   I'll re-run a non-synthetic standard full backup on the troublesome volume/drive, and though it takes days ( 7+ tb afterall ) , it reports to have run successfully.  Then I do an incremental on it.  Then try for another synthetic full....and I get another 671.

Before I open up a support case and have it hanging around in their queue while a backup runs for days creating huge logs and looking bad on their "case days open" reports, I thought I'd ask here for ideas.

Anyone have ideas why 3 of 4 volumes on the same server will create synthetic fulls, but one of them will not?  The 4 policies I use for the 4 drives/volumes are identical except for the "Backup Selections" wherein I list only the drive/volume. 

 

Master and Media servers are all at NBU 7.5.0.6    as is this Windows client (also at NBU 7.5.0.6)

 

Thank you.

1 ACCEPTED SOLUTION

Accepted Solutions

watsons
Level 6

I have seen similar synthetic backup error 671  due to the status 1 job, well.. think it all depend on what files being consolidated into the synthetic backup. For example:

1) Full backup status 1, incr backup status 1, both have fileA busy not being backup. So synthetic backup works fine.

2) Full backup status 0, incr backup status 1 (or vice versa), fileA was backup in full but failed in incr. Synthetic backup may fail trying to look for fileA changes.

Again, there can be many scenarios and it's hard to explain until we really look into what files are being read for the consolidation. I do not know the actual mechanism behind the software but the above looks reasonable to me. 

Your backup is probably too big to ensure a status 0, I would try to isolate/exclude those busy files. At least try to have a status 0 for both full & incr, and check if synthetic backup works that way. If not, I will bring it to Support for further investigation.

View solution in original post

9 REPLIES 9

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

From Status Code manual:

NetBackup status code: 671
Message: query for list of component images failed
Explanation: A new synthetic image cannot be formed because of a problem with
the required component images. For example: a new, synthetic full backup is tried
from the previous full image from Sunday and from the five differential
incremental images from Monday through Friday. This error occurs if any of those
images (except the most recent image on Friday) has expired.
Recommended Action: Run a non-synthetic backup (either a new full or new
cumulative), depending on the type of backup that failed.

 

 I'll re-run a non-synthetic standard full backup on the troublesome volume/drive, and though it takes days ( 7+ tb afterall ) , it reports to have run successfully. 

Is the standard full backup in the same policy?

It will not work if it is in a separate policy.

rookie11
Level 6

please share backup selection of policy or policies.

do a thorough comparison of policy which is running absolutly fine and policy which is not working for synthetic full backup.

Is option "collect true image restore and move detection" checked ???? without this synthetic full will not work.

someoldman
Level 3

Answers to two posts.

Yes, it is the same policy running the standard full as the attempted synthetic full.

Yes,  Collect True Image    and move detection   are both selected.

Backup Selection is      F:\

 

 

 

thesanman
Level 6

Another issue I have seen with non-Windows systems is where a file is made to appear in the file system but the created or modified date is set via some mechanism to be "before" the last backup.  Thus; the actual file is not backed up but it's still referenced.

I have not seen this with a Windows synthetic backup but it could happen; is your differential backup performed based on timestamp or archive bit?  Could it be that a file is being created or modified and then it's archive is being "unset"; thus it's never actually backed up but NetBackup thinks it's there via the TIR information?

watsons
Level 6

 it takes days ( 7+ tb afterall ) , it reports to have run successfully.  Then I do an incremental on it.  Then try for another synthetic full....and I get another 671.

 

OK, the above test you run, make sure both full & incr jobs complete with status 0. Status 1 is not good enough.

Also make sure in master server & the client you can see updated files in \netbackup\tir_info\

Use bpimagelist -U -policy to list your last full & incr backup, check their retention period (not expired), enable verbose bpsynth logs. 

How long did it take for the synthetic backup to complete for other 3 volumes? You need to make sure when synthetic backup is in progress, those images it's consolidating cannot be expiring.

 

someoldman
Level 3

Because there are a large number of files "in use" on this fileserver, NBU is not always 100% in backing up each and every one of those that are "in use"  and I will get a status 1 sometimes instead of status 0. Given that it takes days for any of the 4 volumes/drives to complete a non-synthetic full, getting an exit stat of 1 is generally the norm if I have to do a non-synthetic full.      I would think you might be on to something, except the other 3 volumes/drives have this same thing happen and they do create synthetic fulls successfully.

Reminder:  The other volumes/drives each have their own policy and are run separately. All work just fine in creating synthetic fulls -except- this one volume.

I use Storage Lifecycle Policies to backup everything.  SLP for all is to write to disk first, then copy to tape.  Image retention for weekly full backups are set to 60 days.  Incremental image retention set to 3 weeks.

watsons
Level 6

I have seen similar synthetic backup error 671  due to the status 1 job, well.. think it all depend on what files being consolidated into the synthetic backup. For example:

1) Full backup status 1, incr backup status 1, both have fileA busy not being backup. So synthetic backup works fine.

2) Full backup status 0, incr backup status 1 (or vice versa), fileA was backup in full but failed in incr. Synthetic backup may fail trying to look for fileA changes.

Again, there can be many scenarios and it's hard to explain until we really look into what files are being read for the consolidation. I do not know the actual mechanism behind the software but the above looks reasonable to me. 

Your backup is probably too big to ensure a status 0, I would try to isolate/exclude those busy files. At least try to have a status 0 for both full & incr, and check if synthetic backup works that way. If not, I will bring it to Support for further investigation.

View solution in original post

rookie11
Level 6

suppose ur taking backup of F:\folder4  ---- where synthetic backup fails. please break down F:\folder4 further in to multiple streams.( if u know folder with highest file count its good). backup highest file count folder in different policy. then try regular full + differential   then synthetic backup

someoldman
Level 3

Sorry to only now updating this.  (On holiday and such).

Without me changing anything, it started working again.   

I am thinking "watsons" above may be on to something, but unsure yet so not quite ready to award answer (sorry).

One of my co-workers had to expand that volume just a day or two ago  (due to users never deleting anything), so I expect the next synthetic full to fail  (since it will now be different size) .    I think I will use the July 4th weekend to initiate the long running non-synthetic on the morning of July 3rd.  Then we will see the following weekend whether or not the next scheduled synthetic full works or not.