If you have performed a bulk restore of archived records (as described in KB0680127), you might expect that these restored records will be archived again when the Archive schedule job (Archiver) runs. However, Archiver by design, will not re-archive records that have been manually restored by a user. There might be various reasons that previously archived records are restored, so the Archiver cannot determine whether these restored records should be re-archived. You therefore need to take action to re-archive them, for example, clicking on the Restore record UI action on each record. Currently, there is no option to re-archive manually restored records in bulk.

Steps to Reproduce

  1. Archive a record using an active Archive rule.

  2. Restore that record using the Restore Record UI Action.

    Note that the regularly scheduled job - Archive runs and does not re-archive that record.


Workaround (Pre Paris release):

To re-archive restored records in bulk, consider adjusting the script provided below to clear entries from sys_archive_log ONLY for those restored records you want re-archived. You can put it in a scheduled script execution to make it run periodically to batch through a large recordset.


  • This script will NOT re-archive the records. It sets up the log so that on the next run of the Archive job, these records will get picked up and archived along with the other records that meet the criteria specified in the active Archive rules.

  • Because the sys_archive_log table could be large, you might want to consider options such as the following:

    • Adjust the script to filter on the required records using fields that are indexed as part of the filter criteria, such as a particular datetime when an archive was run (sys_archive_run) or the created datetime. (The fields that are indexed are listed in the Database Indexes tab that you can access by navigating to System Definition > Tables and filtering for name=sys_archive_log.)

    • Limiting the number of records retrieved using gr.setLimit();

    • Running the script in batches.

  • Because the OOB Archive job runs hourly, the script when executed will increase the number of records that fulfill the criteria specified in the active archive rule. This ight cause the Archive job to run past one hour if the default archive rule processing behavior or the number of active archive rules have been increased recently. This increases the likelihood of running into the known issue described in KB0550967 "Archive threads can run in parallel on separate nodes for long running archive processes, degrading performance and adding noise errors to the log."

  • Test in subproduction before implementing in Production.


var gr = new GlideRecord('sys_archive_log');
gr.addQuery('id', recordToArchive); // Use this to specify a record to re-archive
gr.addNotNullQuery('restored');      // Use this to limit to records which have been restored (i.e. records that are currently NOT archived)
gr.addQuery('from_table', tableName); // Use this to limit to records on the table you want to re-archive

while( {
    gs.print("Resetting archive log to re-archive record: " +;
    if (gr.deleteRecord()) {
gs.print("Log entry removed, record ready for re-archive");
} else {
gs.print("Failed to remove entry from sys_archive_log");

Paris Release and later:

If the Auto Rearchive checkbox is checked on an archive rule, the restored record will be automatically rearchived after the specified auto rearchive duration (as part of the Archive job). 

Related Problem: PRB629054

Seen In

There is no data to report.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-09-20 17:14:32