Backup & Recovery for Salesforce
Docker + 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 Salesforce through your container 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 named Salesforce administrator and an approved organization for the initial deployment.
- An inventory of standard and custom objects, relationship fields, and required files.
- A connection identity with the least access needed for the agreed task.
- An API usage budget and a plan for validating source automation during any write test.
Prepare Salesforce
Use a Salesforce sandbox or an approved test scope first. Inventory the objects, fields, and relationships that make up the business record.
Object visibility
Compare the connection account's visible objects and fields with the approved scope. Include custom objects and fields in the sample instead of validating only standard records.
Record relationships
Map parent and child records, reference identifiers, and files. For a recovery test, review required fields, validation rules, and automation that can affect inserted or updated records.
Inspect a small Salesforce record set
In an authenticated Salesforce REST client, use the API version supported by your org and deployment. Describe Case first to review the available fields and relationships, then send this bounded query. The paths below are source API requests, not Vivly endpoints.
HTTP
GET /services/data/vXX.X/sobjects/Case/describe/
GET /services/data/vXX.X/query/?q=SELECT+Id,CaseNumber,Status,AccountId,LastModifiedDate+FROM+Case+ORDER+BY+Id+LIMIT+10What to verify
Compare the returned IDs and fields with the same user's Salesforce view. For larger extracts, follow nextRecordsUrl until done is true; the first response is not necessarily the complete result. Describe output helps establish the field and relationship inventory, not a full backup of org metadata.
Salesforce: query results and paginationPrepare Docker
Prepare a container deployment with explicit network boundaries, persistent storage, and a controlled image version.
Image and configuration
Use the image reference and configuration supplied with your deployment package. Pin the agreed version and keep credentials in your approved secret mechanism rather than the image or source control.
Container networking
Map the routes to the source system and database. A database hostname reachable from the host is not necessarily reachable from a container; validate the route from the deployment network.
State and lifecycle
Identify every persistent volume and its owner. Plan resource limits, logs, restart behavior, and upgrades. Replacing a container must not silently discard the retained data or operating history.
Check the supplied Compose deployment
From the directory containing your approved Compose file, inspect the declared service names and running containers. Replace SERVICE_NAME with an actual name from the first command. These commands do not create or remove containers or volumes.
Shell
docker compose config --services
docker compose ps --all
docker compose logs --tail=50 SERVICE_NAMEWhat to verify
Check for restart loops or connection errors. Confirm that database files, attachments, and application state use the persistent mounts defined by the package. Docker volumes outlive individual containers, but volume deletion still removes that data; a volume is not a backup. Redact secrets and customer data before sharing logs.
Docker: volume persistence and lifecyclePrepare 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.
Create the backup configuration
Open Salesforce Backups and choose Create backup. Enter a Backup name, select Full backup or Incremental backup under Capture mode, and choose the Salesforce objects to include. Set Include files and attachments to match the protection scope.
Capture and inspect the data
Choose Start full backup or Start incremental backup. After the run completes, review the captured objects and records. Use Export this page, Export field definitions, or Export all object records to inspect the snapshot against the expected source data.
Rehearse a restore
Use a backup captured from an approved sandbox or dedicated test dataset: recovery targets the original connected org. Choose Select for restore, then pick Create copies with new IDs or Overwrite existing records by original ID under Restore mode. Decide whether to Restore linked files and attachments and choose Preview restore before an administrator confirms writes.
Set the operating cadence
After the first capture and recovery checks pass, an administrator can choose Run on a schedule, set Repeat every to Hour, Day, or Week, and Save schedule. Assign an owner to review failed runs and periodically repeat the recovery test.
Rehearsal: recover a deliberately changed test record
Connect an approved sandbox as the source org. Capture a small set of test records and a supported file, then make an approved, reversible change to a test field in that same org.
- Browse the completed snapshot and confirm it contains the original field value and required file.
- Select the records for restore and preview either copies with new IDs or overwrites by original ID.
- Have an administrator review warnings and confirm only the intended writes into the original connected org.
- Compare the restore receipt, record mappings, relationships, and file access with the expected result; record elapsed time and automation effects.
Scope of this example
This workflow recovers selected records and supported files to the original org. It does not provide cross-org restoration or a metadata/full-org recovery image. Set up the source in a sandbox from the start when rehearsing there.
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