Live Archive - Getting Started - Text

Anubhav P · yesterday

Getting started with archiving in ServiceNow

A practical guide to moving stale records out of your live tables — keeping your instance fast and your data manageable — without losing access to historical records.

Why archive?

If your ServiceNow instance has been running for a few years, your primary tables have likely accumulated a large amount of data that is no longer operationally relevant: closed incidents from 2020, resolved problems from 2019, CMDB entries for decommissioned servers.

That data sits in your live tables, slows down queries and reports, and makes it harder for your teams to find what matters today.

Data Archiving is ServiceNow's answer to this problem. It moves inactive records out of your primary tables so the data you work with every day stays fast and manageable — while older records remain fully accessible, searchable, and ACL-governed when you need them.

Good to know: Archived records are not deleted. They remain queryable, respect your existing ACLs, and can be restored if needed. Archiving is about moving data to the right tier — not losing it.

Two archiving modes

ServiceNow offers two distinct archiving capabilities. Understanding the difference up front saves confusion later.

	System Archive	Live Archive
Availability	All ServiceNow instances	RaptorDB Professional only
Where data goes	`ar_*` tables in the same database	Object storage (compressed columnar format)
Frees primary storage	No	Yes
Plugin required	No — built-in	Yes — `com.glide.db.columnar.archive`
Minimum platform release	Any	Australia release
Archive rules reused	N/A	Yes — no changes needed

Key point: Archive rules are identical between both modes. If you start with System Archive today and later upgrade to RaptorDB Professional, your existing rules carry over automatically — no rework needed.

Core concepts

Three concepts you need to understand before configuring anything.

Archive rules

Archive rules define which records get archived. Each rule targets a single table and uses filter conditions — typically time-based — to identify records to move. For example: "All Incidents closed more than 150 days ago where Active is false." A single table can have multiple rules, and rules run on a 60-minute schedule by default.

Archive tables

When records are archived, they move to a corresponding ar_* table — for example, ar_incident for the Incident table. On System Archive, these live in your primary database. On Live Archive (RaptorDB Professional), they are backed by object storage.

Destroy rules

An optional policy attached to an archive rule that permanently deletes records after they have been archived for a set duration. If you leave the archive duration empty, records are destroyed immediately on archive. Destroy rules are irreversible — plan carefully before enabling them.

Getting started: System Archive

Available on all instances — no additional licensing needed. Here is the complete setup flow.

Understand what you have first. Open the Data Management Console (All > System Data Management > Data Management Console) and review the table-size and growth trend views. This tells you where archiving will have the most impact before you write a single rule.
Create an archive rule. Navigate to All > System Archiving > Archive Rules > New. Set the Name, select the Table you want to archive, and build your filter conditions. A typical Incident rule looks like: Closed → relative → on or before → 150 → Days → ago AND Active → is → false.
Preview before committing. Click Recalculate Archive Estimate to see exactly how many records match your conditions. Confirm the number looks right before the rule ever runs.
Activate the rule. Check the Active checkbox and submit. The archive job runs every 60 minutes by default. You can also trigger it immediately via Run Archive Now — note that a Data Management Policy must also be active for this to work.
Verify. Navigate to All > System Archiving > Archive Tables to confirm records have moved to the corresponding ar_* table.
Optional: create a destroy rule. On the archive rule form, select Create Destroy Rule and set the Archive Duration (how long records sit in the archive before being permanently deleted). Only enable this if you have a clear retention policy.

Getting started: Live Archive (RaptorDB Professional)

If you are on RaptorDB Professional (Australia release or later), enable Live Archive to physically move records and attachments to object storage — freeing your primary database and delivering the full performance benefit.

Prerequisites: RaptorDB Professional subscription, Australia release or later, and at least RaptorDB Professional version 35.1. Admin role required.

Install the plugin. Navigate to All > Application Manager, search for "Live Archive", and install com.glide.db.columnar.archive. During installation, any existing archived data is automatically converted to compressed columnar format and moved to object storage. Normal instance operations are not affected — only archive rule processing is paused, and it resumes automatically when done.
Verify the S3 facade. Navigate to sys_service_endpoint_list.do, filter by s3_facade in the Name column, and confirm two endpoints exist with Active = true. These endpoints (one per datacenter) confirm the storage layer is ready and provide high availability if one datacenter is unavailable.
Confirm the Object Storage tile. Open the Data Management Console. You should now see an Object Storage tile. Storage stats refresh once daily and reflect compressed sizes. The tile populates only once an archive table exceeds 512 MB or 2 million rows, so it may take some time to appear after the first archive run.
Your existing archive rules are already working. No changes to your rules are needed — Live Archive picks them up automatically.

What you can and cannot archive

Most tables — including task and all its extensions (Incident, Problem, Change Request) — support archiving. The following tables cannot have archive rules created for them:

sys_audit and audit variants
sys_attachment — archived automatically with the parent record
sys_journal_field — archived automatically with the parent record
Internal system tables

Note on attachments and journal entries: You do not need a separate archive rule for attachments or journal entries. They are automatically archived and destroyed alongside their parent record.

Tips before you start

Validate conditions in a list view first. Before creating an archive rule, run the same filter on the live table as a list view to see exactly which records match. An overly broad condition could archive records your team still needs.
Check for conflicting rules. If you already have a 90-day and a 180-day rule for the same table, one may interfere with the other. Audit existing rules before adding new ones.
Use relative date operators. Conditions like "relative — before — 2 years ago" stay accurate over time without manual updates. Avoid hardcoding specific calendar dates.
Never delete Archive Log entries. Each sys_archive_log record is the only mechanism for restoring an archived record. Deleting one makes restoration permanently impossible.
Plan the Live Archive migration window. Plugin installation pauses archive rule processing during the migration to object storage. Schedule it during a low-activity period.
Monitor the Data Management Console regularly. The "Records in backlog" column (refreshed daily) shows how many records match a rule but have not been processed yet — useful for spotting bottlenecks early.

What to explore next

Related records archiving — configure archive rules to cascade to child records (journal entries, related tasks) alongside the parent, with control over whether to archive, clear the reference, or delete.
Destroy rules with retention windows — set up data retention policies that permanently remove archived records after a defined duration (for example, seven years for compliance).
Data Management Console monitoring — use the backlog and table-growth views to track archiving progress over time and identify new tables that need rules.
Auto-rearchive — enable this flag on any rule to automatically re-archive a restored record after a set duration, preventing live tables from growing again after one-off restorations.