Video Screencast Help

EV 9.0.3 no backup detected on closed partitions

Created: 09 Apr 2013 • Updated: 05 May 2013 | 10 comments
Sarah.Seftel's picture
This issue has been solved. See solution.


Weird issue, where I have aroung 20 closed partition, and in the awaiting backup in usage.asp i have almost 4 million items.

in some partitions backup tab I see that last scan was about a year ago.

In some partitions I see in backup tab "no backup detected".

run the SQL script

didn't do anything... I have ignorearchivebittrigger.txt files in those partitions, and it's not scaning at all.

any ideas?


Operating Systems:

Comments 10 CommentsJump to latest comment

JesusWept3's picture

any chance of getting a dtrace of storagefilewatch and then restarting the Storage Service?
Also do the IgnoreArchiveBitTrigger.txt remain as .txt or does it get renamed to .old?
Also what is the create date of the trigger file?

Sarah.Seftel's picture

Will create the trace in an hour or so.

I created a fresh new ignorearchivebittrigger.txt files.

they stay as TXT, not turning to old at all...

GertjanA's picture

Hello Sarah,

How do you set/clear backup mode? Do you do that on site-level?

If yes, try doing it per store. Long, long time ago, there was an issue like this (see

Can you make sure that the (apologies if you know and do!) triggerfile has the current date time, then set the backup mode manually, and clear manually on the Vault store.

Does the file change to .old ?



Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS

Sarah.Seftel's picture

Hi Gertjan,

I read your forum thread, but I'm sure this was handled by now, as I have many customers that have backups in site level, ana txt does turn to old.

the current time and date of the file is fresh from yesterday, I deleted the old trigger file from before and created fresh ones.

I will check the manually change backup mode and clearing manually and update!

Saswata Basu's picture

I would be interested in the Dtrace log of StorageFileWatch process after clearing the backup (if this EV 8.0 or later) or restart the storage service(for EV 7.5 and earlier).

Old Man Jensen's picture

So I'm wondering if EV actually considers these items as not having been backed up, or if these are records that're just stuck in the journalarchive table?

If you have a moment, you might want to run the following queries on the vault store database:



FROM JournalArchive


and then,



FROM JournalArchive

WHERE BackupComplete = '0'


If the counts are equal, then at least you know that EV isn't processing the trigger file for some reason.  But if the count of items with BackupComplete at zero is at or close to zero itself, then the problem has to do with EV not clearing records from the JournalArchive table.

Jason Jensen

Director – Archiving & eDiscovery | Verizon Terremark

YouTube | LinkedIn

Sarah.Seftel's picture

this actually solved the issue.

We only restarted storage service and not all EV services.

After restart of all services - issue solved.