Unable to bulk re-archive restored records - Known Error

Unable to bulk re-archive restored records Description 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

Archive a record using an active Archive rule.

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 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.

Notes :

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.

Script :

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 gr.query();

while(gr.next()) { gs.print("Resetting archive log to re-archive record: " + gr.id); 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). Note that the Auto rearchive option will rearchive all restored records regardless of the condition in the rule.

To rearchive restored records conditionally, you can use the below script.

var gr = new GlideRecord(‘Table_To_Archive_From’); gr.addQuery(); Write Query to fetch records you want to rearchive gr.query();

while (gr.next()) { if (gr.get(gr.sys_id)) { var archiver = new GlideArchiveRecord(); archiver.archive(gr); } }