It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Campus Barracuda Campus

Attention

Starting May 1st, 2018, we will no longer offer the ArchiveOne family of products. This includes all editions of ArchiveOne, ArchiveOne for Files, Max Compression, and Access Security Manager. If you currently hold a maintenance and support contract, you will continue to receive our award-winning support until your contract expires, or until May 1st, 2019, whichever occurs first. The license for ArchiveOne is perpetual; therefore the software may continue to be used independently without any updates or support indefinitely.

Understanding Check Files

  • Last updated on

Check Files contain log files, and are located in the ArchiveOne installation directory, by default, C:\Program Files (x86)\Barracuda\ArchiveOne\ServerData\_PoliciesCheckFiles, including:

  • Message_XXXX.log
  • Policies_XXXX.log
  • Repositories_XXXX.log
  • Zip_XXXX.log
  • MessagesToBeSkipped.mdb

Naming Conventions

The check file naming convention appends a four-digit ID that relates to the thread ID in the ArchiveOne Service trace to correlate the logs.

Message Check File

When ArchiveOne processes messages, it writes a Message Check File, for example, Message_1358.log, to the _PoliciesCheckFiles folder containing information about the message currently being processed. Under normal operation, a new check file is created as each message is processed, and the old check file is removed once processing completes successfully. If unexpected behavior is encountered and processing is disrupted, the Check File for the last processed message is retained. When ArchiveOne Service restarts, it reads this last check file and creates an entry the failed message in the Message to be skipped Database (MessageToBeSkipped.mdb) located in the _PoliciesCheckFiles folder. ArchiveOne stores this list of messages that should not be processed in this database. Whenever a policy runs, it checks each message for processing against the Message to be skipped Database, and if there is a match against an existing database entry, the message is skipped by the policy.

Disruptions to processing may not be due to a message but to other unrelated events. This can lead to messages being stored in the database which may not actually be problematic to processing. To resolve this, Barracuda Networks Support may recommend that you flush this database to force re-examination of skipped messages.

Policy Check File

During the first phase of a policy a Policy Check File, for example, Policies_1884.log, is generated containing the name of the current running policy. If the ArchiveOne Service is restarted, for example, if the Archive Server is restarted, before the policy completes, this file is ready by the ArchiveOne Service when it starts up again. The ArchiveOne Service then automatically re-runs the disrupted policy.

Barracuda Networks Support may recommend that you remove this file as this behavior can cause a policy to loop continuously. For instance, if the policy causes the ArchiveOne Service to crash, once the service restarts it reads the check file and re-starts the same policy. If the policy then causes another service crash to occur in the same way, the cycle will continue.

Repository and Zipmaker Check Files

In the second phase of a policy, the Policy Check File from phase one, for example, Policies_1884.log, is removed and replaced with a Repositories Check File and a Zipmaker Check File, for example, Repositories_1884.log and Zip_1884.log. The Repository Check File contains the name of the current repository to which content is being archived, and the Zipmaker Check File contains information regarding the message currently being archived. If the ArchiveOne Service is disrupted, these check files are ready once the service is restarted and the second phase resumes.