Why is Archive bit not reset at the end?

[pablohassan]

Hi all!
I know that Backup Exec resets archive bit during the actual backup so just after the file goes to tape, it has it's bit reset to 0.

My backup looks like this:

FRIDAY 1 - FULL BACKUP
MONDAY - THURSDAY - DIFFERENTIAL BACKUP
FRIDAY 2 - FULL BACKUP
MONDAY - THURSDAY - DIFFERENTIAL BACKUP
FRIDAY 3...

Now, imagine that something went wrong with FRIDAY 2 backup - it was completed in just 10% and failed for any reason - job cancelled, software error, blue screen. And I found it on Monday morning (full backup runs on Friday because of amount of data).

Job failed but 10% of the files had archive bit reset to 0. Next differential Monday backup will refer to FRIDAY 2 and not to FRIDAY 1.

And to be honest, it doesn’t make any sense for me. Before I even touched backups - I thought that archive bit will be reset only if backup finishes successfully (verified or not). But in reality I can have situation where data was saved on tape and in the verification process I found that actually I need to replace the tape as there are too many errors.

Common sense is telling me that because this backup wasn’t successful and I can’t restore this data - my Monday differential should refer to last full successful Friday - #1 in this case. Unfortunately, it’s not. It’s possible that I can have situation where on FRIDAY 2 morning (backup starts on the evening) someone did a change to the file. File wasn’t successfully saved to the tape but source file had archive bit set to 0 so next differential Monday backup will not pick it up.

I hope it all makes sense.

 

[intelwizrd]

The archive bit gets reset when the file is backed up. It is likely that although the job failed, some of the files were backed up. The verify operation happens after it is finished with the back up and functions only as a sanity check with what is in the backup and what is on the disk. Also, these can fail if you have something changing the file right after it gets backed up. It is good to do it but this step happens outside of the actual backup process. Now as for your backup chain consider the following based on your example:

2 files (file1, file2)
both get backed up on Friday1 and archive bit is 0
both get modified durring the week and archive bit is 1 for both
full backup on Friday2 FAILED at 50%, file1 archive bit is 0, file2 archive bit is 1
differential backup on Monday2 backs up file2 but not file1
complete system failure happens after differential backup completes on Monday

Here is what you do,
Restore Full backup from Friday 1,
Restore Thursday1 Diff,
Restore any data from Friday 2,
Restore Monday2 Diff.
All of your files should be restored to as they were at the time of backup on Monday2.

Because the backup on Friday 2 never finished it didn't reset the archive bits on the files it didn't get to so the differential on the following Monday, backed up all of those files as well as the ones that were backed up and were changed over the weekend. You just have to start your restore process farther back.


If I missed something in my logic, let me know. Still on my first cup of coffee this morning.

 

[pablohassan]

Thanks for reply.
For me, unfinished backup is something I wouldnt rely on. There are too many possible reasons, some of them will actually mean the data loss.

I just cant understand why is archive bit reset during the backup, not at the end.