Forum Discussion

3 Replies

  • Thank you for reply.

    "The NetBackup Enterprise Vault agent resets the archive bit on the files that were backed up in FULL and DIFFERENTIAL schedules."

    We are using same schedules as technote. But for differential incremental backup does not clear the archive bits.


  • When EV archives an item, it is not deleted from the original location immediately.  The item is left in a “pending” state until the archive location (partitions) has been secured (backed up).  These items are referred to as Safety Copies. 

    The backup process is only going to “secure”  the items that were in the partition at the time of the snapshot.  Anything archived after the snapshot has been taken will not be included in the backup, and therefore will not be considered “secured”.  Because of this, the newly archived items will remain in a pending stated until the next backup run. 

    Enterprise Vault knows to process Safety Copies based on archive bits OR a trigger file.  You can choose which method to use from the partition properties within the EV Admin Console.

    If you choose archive bits (default) you will always be one backup behind on processing safety copies.

    If you choose trigger file method, you can have EV check to see if the trigger file has been updated according to a timer (60 minutes by default).  If the trigger file has been updated (by the backup software) it will consider the partition secured and process safety copies.  If the trigger file hasn’t been updated, no action will be taken.

    At the end of the backup, the NetBackup EV Agent will to both:

    -clear archive bits for the items it backed up, and
    -create/update the trigger file at the partition root  (partitionsecurednotification.xml)

    In your situation, the trigger file option was provided as a workaround to your issue, not an actual solution.  Using the trigger file option will allow EV to process your safety copies in a timely manner which will prevent your mailboxes from filling up.  You can continue using this workaround while Support investigates why the archive bits are not being cleared at the end of the diff-incr backup.