Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

archive bit not clearing from specific items...

Created: 14 Jan 2013 • Updated: 05 Feb 2013 | 10 comments
Sarah.Seftel's picture
This issue has been solved. See solution.

Hi

EV system, with ignorearchivebittrigger.txt set, every morning after snap of the storage we replace the ignorearchivebittrigger.old with a fresh new txt file.

awaiting backup resets to 0 and all is good.

starting a week ago - I'm stuck with 60,050 items in daily alert.

so... if I archive 10000 items, it will go up and be 70,050 items that have not been backed up yet, and tomorrow morning after the ignorearchivebittrigger.txt will be replaced - it will "reset" back to the number 60,050...

something is stuck sad

will appreciate your help and ideas.

Sarah.

Comments 10 CommentsJump to latest comment

Topper454's picture

Hi

Is this File System Archiving ?

If so what do the archive task log files say, are there a high number of errors?

Maybe the  errors are to do with offline files?

Regards

Topper 454

Sarah.Seftel's picture

Failed to mention - Exchange archiving only.

no offline files.

the dbo.watchfile not clearing those 60,050 dvs files....

ManishN's picture

You may need to check watchfile table and also initiate dtrace on storagefilewatch and see if any things comesup. you can upload if it's not a big one.

Regards,

MN

Jeff Shotton's picture

Sarah,

Are there 60,050 items in the watchfile table? i.e have you actually checked?

Have you checked the path in the table to look for those items? Do they still have the archive bit set?

Which version of EV - the processing of this table changes slightly between different versions.

Regards.

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

Sarah.Seftel's picture

yes to all first 4 questions smiley

don't remember the version 9.0.X...

will check tomorrow.

JesusWept3's picture

Yeah when it complains about 60,050 items, you will want to do a quick couple of queries

SELECT COUNT(*) FROM WatchFile
SELECT COUNT(*) FROM JournalArchive WHERE BackupComplete = 0

If it genuinely is coming out as 60,050, then you should do
SELECT TOP 100 * FROM WatchFile

Look at the relativePath that is returned (the path to where the DVS file can be found)
Make sure that the paths returned genuinely contain the IgnoreArchiveBitTrigger.txt at the root.
If the .old file exists, check what its create date is and make sure its not really old.

Depending on the version, it could possibly be that the partition is set to use the Archive Bit and not the trigger file? in which case you will need to set the properties to look at the file....

IF the counts come back way lower than 60,050 then you would want to recreate the statistics for the vault store databases, as I have seen in the past where it reports an incorrect amount of items in a particular table

One of the more obscure things could be that you have the vault store database in a really old compatibility mode, and it causes the watchfile table to clear out incorrectly, but if that were the case I would expect the numbers to grow and grow and grow

Sarah.Seftel's picture

I'm not in front of the server now, but from what I checked at noon:

I did opened the watchfile table, it contains 60,050 rows.

I checked few of the paths, they all contain dvs files with 'a' attribute.

The partition is configured to use trigger file, in fact, items are being cleared from their archive bit, except those 60,050 item.

I will check the DB compatibility mode as this one I don't recall checking.

JesusWept3's picture

OK So i'm a bit confused, Are you relying on the Archive Bit to be removed from the individual files or are you using the Archive Bit Trigger file (i.e the IgnoreArchiveBitTrigger.txt or Partition Secure Notification XML file?)

They both solve different problems and if you have a file system that will support archive bits and backup software that removes the archive bit and not using anything like Flash backup or NDMP etc then you should just rely on the StorageFileWatch to scan for the archive bit attribute

If you are using something like CIFS or netapp etc or use software that does not clear the archive bit, then you should configure the partition to look for the IgnoreArchiveBitTrigger.txt file and then create the file after the backup has completed and before you bring storage out of backup mode.
 

So....In this scenario, you have items that are legitimately not being seen as backed up, they have the Archive Bit attribute still set.....

The partition those items belong to, how is it set up? Trigger file or archive bit scan?
If its the archive bit scan and your items still have the archive bit, then you will need to make sure that your backup is getting those files and removing the archive bit attribute, you could also run an attrib -a command to remove the attribute to get past it.

If the partition those items belong are set to use the IgnoreArchiveBitTrigger.txt then you need to ensure that the TXT file is created in the correct location at the root of the path, that its create date isn't too old and that its being placed in the directory before storage comes out of backup mode.

One thing to note is that EV does not remove the Archive Bit, so even though theres a file saying ignoreArchiveBitTrigger.txt, it means just that, it will ignore the items, and simply remove the watchfile entries and set backupcomplete to 1.

So when using the IgnoreArchiveBitTrigger.txt, checking the items Archive attribute is not a good way to determine if the trigger mechanism is functioning correctly or not

SOLUTION
Jeff Shotton's picture

As Alex said....and also...

So something is clearing the archive bit (part of your snap process?) but you are using the trigger file mechanism? 

You stated that the other files are having the archive bit cleared...

EV doesn't clear down the archive bit. So something is

The trigger file will only clear down items where the trigger file is NEWER than those items, otherwise they will remain unprocessed. But it doesnt *sound* like the trigger file is being used here.

Assuming NEW files are being cleared down correctly, and you are SURE that these files are being backed up, what happens if you clear the archive bit from one of these 'stuck' files (maybe the first one...)

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

Sarah.Seftel's picture

problem solved smiley

we are using the trigger file mechanism.

However - after some more checking, it turns out the customer changed the active partition to an old partition and than switched it back to the new partition.

items in the old partition were set to be cleared by archive attribute and not trigger file.

I did change the setting back smileytrigger file, and he changed it back to attribute...

I changed it back to trigger file now - and it's Finlay clearing.

it's a classic case of the customer touching the system and not knowing what is he doing...

thanks everyone smiley