Data Archiving for ServiceNow
Linux + MySQL
Configure an archive workflow that keeps historical records useful while separating retention from everyday operations.
What you will leave with
An agreed archive scope, a verified destination copy, and a retrieval test before any source cleanup is considered.
In this guide
Deployment model
Configure a defined record scope in ServiceNow, run the archive workflow on your Linux host, and retain the resulting data in the selected database.
- Make record selection explicit: object or table, fields, date and status filters, related records, and attachments. Keep exclusions in the same configuration record.
- Review retained-data access separately from source sharing and field permissions. Define who can browse, export, or use archived data through an agent.
- Treat source cleanup as a separate approved operation. Validate the retained copy, dependencies, retention requirements, and recovery procedure before authorizing deletion.
Use the installation package and version-specific configuration supplied for your deployment. This guide covers the source, host, database, and workflow decisions that remain consistent across package versions.
Before you begin
Bring the application owner, infrastructure owner, and data owner into the same deployment review. Agree the boundaries before configuring a connection.
Decisions to make together
- Which records are inactive, and what makes them eligible for archiving?
- Which related records and attachments must remain available together?
- Who sets retention periods, handles holds, and authorizes source deletion?
- A ServiceNow administrator and an approved non-production instance.
- An inventory of tables, reference fields, inherited fields, and attachment requirements.
- An agreed integration identity and a review of the instance access rules.
- The connection authentication method and a list of permitted operations for this workflow.
Prepare ServiceNow
Define the ServiceNow instance, tables, and access rules for the workflow. Use a non-production instance to validate the configuration before applying it to production.
Table and field scope
List required tables and fields, including inherited fields and reference values. Include a record with related tasks or attachments when validating whether the scope is complete.
Access and business rules
Review table and field access with the instance administrator. For any proposed write operation, identify business rules and flows that may run, and agree how the test will be isolated.
Inspect a small ServiceNow record set
Use the REST API Explorer or an approved authenticated REST client against your non-production instance. This example requests ten incidents and their stored reference values. Adjust the table and fields to your approved scope.
HTTP
GET /api/now/table/incident?sysparm_query=ORDERBYsys_id&sysparm_fields=sys_id,number,short_description,caller_id,sys_updated_on&sysparm_limit=10&sysparm_display_value=falseWhat to verify
Check the result array against records visible to the integration identity. Preserve sys_id values for matching; display labels are not stable record keys. An empty result can reflect the query or permissions. For a larger extract, define pagination and reconcile changes during capture. Download required attachment bytes through the Attachment API; a metadata row alone does not preserve the file.
ServiceNow: Table API parameters and responsesPrepare Linux
Prepare a Linux host with a dedicated application identity and an agreed operational model. Record the distribution and package version for your selected product.
Runtime and service account
Install the runtime required by the deployment package. Use an application account with scoped filesystem access and record who manages the service lifecycle.
Network and trust
Validate source and database routes, DNS, proxy settings, and certificate trust. Keep application access limited to the agreed network and avoid embedding credentials in scripts or shell history.
Persistent storage
Plan persistent locations for data and logs, with disk alerts and a recovery procedure. Check restart behavior and the handling of interrupted work before adding a schedule.
Check the Linux host
Run these read-only checks on the application host. Compare the distribution and architecture with the requirements for the supplied package, and identify the filesystem that holds persistent state.
Shell
cat /etc/os-release
uname -m
df -h
systemctl list-units --all --type=service 'vivly*'What to verify
Record the distribution, architecture, capacity, and installed service state. Native systemd packages need an operational service manager. An empty Vivly service list before installation is expected; after installation, reconcile it with the package's required units.
Prepare MySQL
Prepare a MySQL destination with a dedicated application database, a scoped connection identity, and an approved authentication method.
Compatibility and connection
Record the server version, driver, authentication plugin, and TLS configuration. Validate the connection from the application host using the connection identity that will run the workflow.
Types and encoding
Include non-ASCII text, nulls, precise numbers, long text, and date values in the validation dataset. Review character set, collation, and SQL mode when comparing source values with the stored result.
Capacity and ownership
Agree the account's schema privileges and the owner of database backups and maintenance. Measure storage growth during the first run and document restart and reconnect behavior.
Check the MySQL connection context
Run these read-only statements after selecting the intended database with the application identity. Inspect character encoding and SQL mode before comparing text and date values.
SQL
SELECT DATABASE() AS database_name,
CURRENT_USER() AS authenticated_account,
VERSION() AS server_version;
SELECT @@character_set_database, @@collation_database, @@sql_mode;
SHOW SESSION STATUS LIKE 'Ssl_cipher';What to verify
Confirm the database and authenticated account. A remote TLS connection should report a cipher. With the MySQL command-line client, --ssl-mode=VERIFY_IDENTITY and the appropriate CA verify the hostname as well as the certificate; a cipher by itself does not prove those checks ran.
MySQL: connection and TLS verification optionsConfigure the workflow
Start with a representative dataset, then expand the scope after validation. Use the connection settings established above and keep source changes behind the appropriate approval.
Define the archive boundary
Choose a small set of records using an explicit business rule, such as closed status and an agreed age. Record exclusions, linked records, required fields, and attachment requirements. Treat a retention hold as a separate decision from age.
Review a representative sample
Include records with custom fields, missing values, long text, dates, and relationships. Agree how identifiers and relationships will be represented at the destination before expanding the scope.
Validate the retained copy
Compare record counts and sampled field values with the source. Exercise the retrieval workflow that the business will actually use. Include a user who should have access and one who should not.
Make cleanup a separate decision
Do not use a completed transfer as proof that source records can be removed. Approve a cleanup policy only after retention, dependencies, retrieval, and recovery requirements have been reviewed.
Pilot: preserve a completed service record
Select a small set of completed incidents with a reference, a journal history requirement, and an attachment. Name the exact related tables and fields to retain alongside each incident.
- Record the sys_id and expected related records for each incident before capture.
- Compare stored reference IDs and required journal entries with the approved source sample.
- Open a preserved attachment and verify its bytes or checksum, not just its filename.
- For an instance-retirement evaluation, verify retrieval from the retained copy with source access disconnected in the test environment.
Scope of this example
Archive copying does not delete ServiceNow records or reclaim instance storage. Explicitly select journal and audit scope; do not infer complete history from the current incident row.
Validate before expanding
- The selection rule includes the intended records and excludes held or active records.
- Source identifiers and required relationships can be traced in the retained data.
- A business user can retrieve an agreed historical case using the intended access path.
- Retention, source cleanup, and recovery responsibilities have named owners.
Keep a deployment record
Record the package version, environment, data scope, test date, expected result, actual result, and owner of each unresolved issue. Keep secrets and customer data out of shared support notes.
Everyday operations
After each run
Review completion status, record counts, failures, and source API usage. Resolve unexpected differences before allowing the next dependent action.
When credentials change
Update the connection through the approved secret process, verify a bounded read, and retest the required operations. Remove obsolete credentials.
When the source changes
Review added or changed objects, fields, access rules, and automation. Repeat representative data and permission checks before expanding the scope.
Before an upgrade
Record the current package and configuration, protect persistent data, and define the rollback procedure. Validate connectivity and a representative workflow after the change.
Troubleshooting
The archive contains fewer records than expected
Compare the selection rule, source account visibility, date boundaries, API responses, and excluded record types. Reconcile counts before changing the scope.
A historical record lacks useful context
Check whether related records, custom fields, and attachments were included. Test retrieval across the complete business case rather than a single row.
A record should not be removed
Stop the cleanup step and review active dependencies, retention holds, and the approved deletion boundary with the data owner.
MySQL values differ from the source
Compare encoding, collation, numeric and timestamp types, and SQL mode. Use a representative sample and inspect failed or truncated writes before expanding the dataset.
Technical references
Use these official references for the source APIs, database connection settings, and runtime behavior discussed above. They describe the underlying platforms; use your Vivly package documentation for its installation and supported configuration.
Review this deployment with Vivly
Bring your source scope, host, database, and success criteria. We will use them to identify the applicable package, open questions, and rollout sequence.
Book a demo