Backup & Recovery for ServiceNow
Windows + Embedded PostgreSQL
Set up a protection scope, define a recovery procedure, and validate that restored records support the business process.
What you will leave with
A documented protection scope and a recovery rehearsal with measured results, exceptions, and clear ownership.
In this guide
Deployment model
Configure a protection workflow from ServiceNow through your Windows host into the selected database. Define recovery as a tested operation with an agreed destination and approval path.
- Separate the capture identity from the authority to write restored records. Give each the access required by its task and document the people who approve recovery.
- Define whether the protection scope includes records, relationships, files, and configuration. A record count alone does not establish that a business process can be recovered.
- The application's retained data and the destination database need their own operating procedures. Test both record recovery and the database recovery process against business requirements.
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
- What data loss and service interruption can the business tolerate?
- Are files, metadata, relationships, and custom fields required in the recovery scope?
- Where can a restore be tested without changing production records?
- 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 Windows
Prepare a Windows host whose ownership, service identity, and network routes are agreed with your infrastructure team.
Host and process ownership
Record the Windows release and deployment package version. Choose the account that will run the application, its file permissions, and the team responsible for restarts and upgrades.
Network and certificates
Review outbound access to the source and connectivity to the database, including proxy and certificate requirements. Limit any inbound application access to the approved network.
Storage and operations
Identify directories for application data and logs. Agree disk monitoring, credential rotation, restart checks, and the maintenance window before scheduling work.
Check the Windows host
Run these PowerShell checks on the application host. The service query shows installed Vivly services, if present. Compare the result with the service list supplied for your package.
PowerShell
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, OSArchitecture, Version
Get-Service | Where-Object DisplayName -Like '*Vivly*' |
Select-Object DisplayName, Status
Get-PSDrive -PSProvider FileSystem |
Select-Object Name, Used, FreeWhat to verify
Record the OS and available storage. After installation, required services should be running. Check both the service account's database access and its ability to read the configured certificates; success from an administrator's interactive session does not establish service access.
Prepare Embedded PostgreSQL
Define the PostgreSQL database, schema, account, and storage owner. For a Windows embedded setup, identify the database service and persistent data directory created by the package.
Connection and privileges
Record whether PostgreSQL is embedded or separately managed, its version, and the connection configuration. Review the required database and schema privileges rather than granting broad administrative access by default.
Data representation
Test timestamps and time zones, numeric precision, large text, and source identifiers. Compare reference identifiers with the source and test how a changed source field appears at the destination.
Storage and recovery
Plan database capacity, growth monitoring, and database backups. For an embedded deployment, identify the data directory and verify that application upgrades or host replacement preserve it.
Check the PostgreSQL connection context
Connect to the intended archive or backup database with the application role, then run this read-only query. For embedded Windows installations, use the endpoint and port recorded by the installed package.
SQL
SELECT current_database() AS database_name,
current_user AS database_user,
current_schema() AS schema_name;
SHOW server_version;
SHOW TimeZone;What to verify
Confirm the database, role, schema, and time zone before comparing source values. For remote libpq connections, sslmode=verify-full validates both the certificate chain and hostname when the trusted CA is configured. An encrypted connection alone does not prove the server's identity.
PostgreSQL: TLS and server certificate verificationConfigure 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.
Set the recovery objective
List the incidents you need to recover from: accidental deletion, a bad update, or a failed integration. Agree the acceptable data loss and restoration time with the business owner; measure these during validation rather than assuming a service guarantee.
Choose a representative protection scope
Identify the required objects or tables, relationships, attachments, and configuration dependencies. Record the minimum set that makes a recovered business record usable.
Design a recovery rehearsal
Use a sandbox or a dedicated test dataset. Define how restored records will be matched, how conflicting changes will be handled, and who approves writes. Record the restore target and matching policy before executing the test.
Record the result
Compare restored values and relationships against the expected state. Capture elapsed time, failed records, retry behavior, and any manual actions. Keep the recovery procedure with the people responsible for operating it.
Rehearsal: validate one service recovery scenario
With the platform owner, choose a non-production service record and document the unwanted change you need to recover from. Agree the supported capture and restore procedure for your deployment before executing it.
- Record the pre-change field values, sys_id, references, required journals, and attachment checksums.
- Confirm the retained data covers those requirements and record any exclusions.
- Review the proposed recovery target and writes, including business rules and flows they may trigger.
- Use the agreed recovery procedure, then have the service owner validate record usability and measure the result.
Scope of this example
A Table API export is not a full-instance backup. Verify the delivered recovery capability, identifier handling, journal behavior, and target-instance support before adopting this rehearsal as a production runbook.
Validate before expanding
- The protection scope lists both included data and explicit exclusions.
- A representative recovery has been rehearsed in an approved test environment.
- Restored records retain the fields and relationships required by the business process.
- Measured recovery time, data coverage, and unresolved exceptions are documented.
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
A recovery test cannot recreate the expected state
Review the captured fields, source identifiers, parent dependencies, and destination permissions. Check whether automation or validation rules affect writes.
The recovery window is too long
Separate time spent retrieving data from API throttling, dependency ordering, and manual review. Revisit the scope and objectives before promising a shorter window.
Recovered records conflict with newer changes
Pause further writes and review the matching and conflict policy. Avoid rerunning the same operation until duplicate and overwrite behavior is understood.
PostgreSQL rejects a connection or write
Check the endpoint, database name, account, TLS settings, network access policy, and schema privileges. For embedded deployments, also check process health and available disk space.
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