RASP Vault documentation

Getting started

What RASP Vault does

RASP Vault keeps a continuous, searchable copy of your Salesforce org on infrastructure you control. It backs up:

• Records — every object your integration user can read, with full change history, deleted records and formula values.
• Files and attachments — every version of every Salesforce File, legacy Attachments and Documents, and any other binary field.
• Configuration metadata — layouts, flows, Apex, profiles, permission sets, objects, reports and every other metadata type the org has.

Each Salesforce org you protect is an instance. Every instance backs up into its own database, and a share of your org's daily API allowance that you choose — so backups never starve your other integrations.

Signing in

RASP Vault never creates a password for you. A super admin invites you, and you choose your own password from a single-use link.

1. Open your invitation link. It works once, and for 48 hours. If it has expired, ask a super admin for a new one.
2. Choose a password of at least 12 characters. Length matters more than symbols: a short sentence works well.
3. Sign in at rasp-vault.sf-backup.com with your email address and the password you chose.

Staying signed in

• A session ends after 60 minutes without activity, and in any case 12 hours after you signed in.
• Remember me keeps only your email address in this browser. Your password is never stored.
• Sign out ends the session on the server immediately, not just in your browser.

Too many attempts

After five failed sign-ins for the same address within 15 minutes, further attempts are refused for a while. Every attempt is recorded in sign-in history, including where it came from.

Roles and permissions

There are two roles. Neither can grant itself more access.

Buttons you cannot use are hidden, and the server checks every request independently — hiding a button is a courtesy, not the protection.

The dashboard

The dashboard is the first page after sign-in and answers one question: is everything being backed up?

• Instances, Running, Paused and Needing attention count your instances and jobs at a glance.
• The Instances list shows each org's status and when it last synchronised.
• Recent jobs lists the latest backup runs across every instance. Select one for its details.

Salesforce instances

Registering an instance

An instance is one Salesforce org — production or sandbox — and the database its backup is written to. Super admins register instances.

1. Open Instances and choose Register instance.
2. Name it and pick the environment — Production or Sandbox. Sandboxes sign in through Salesforce's test login automatically.
3. Enter the backup database: host, port, database name, user and password. Leave the password blank only for socket authentication.
4. Choose Test this database. RASP Vault proves it can connect, and that the user can create, alter and drop a table. Nothing is registered until this passes.
5. Set the backup settings: the API budget percentage (10% by default), the timezone, and whether to back up files and attachments.
6. Choose Register instance. The next step is connecting Salesforce.

A database can belong to only one instance. Registering a second instance against the same database is refused, so two orgs can never overwrite each other's backups.

Connecting to Salesforce

RASP Vault connects through a Connected App you create in your own org, so you stay in control of access and can revoke it at any time.

On the instance page, the Salesforce card carries an Authorise button in its header; it opens a window with the callback URL to copy and the Connected App details to enter. Once an org is connected, the card shows which org it is, in three columns: the organisation (name, Org Id, Production or Sandbox with the edition, Salesforce instance, namespace, country, locale, language, time zone, fiscal year, primary contact, address, when the org was created), who authorised it (name, email, username, alias, profile, role, user type, whether API access is enabled, last login) and the connection (when it was made, My Domain, the sign-in host, API version, the Consumer Key's ends, whether a refresh token is held, and the org's API and storage entitlements). It is all read from Salesforce when authorisation succeeds and stored with the instance. Refresh details reads it again without re-authorising — an org connected before this existed fills in by itself the first time its page is opened.

1. Create a Connected App in Salesforce

In Salesforce, go to Setup → App Manager → New Connected App and set:

Salesforce can take several minutes to activate a new Connected App.

2. Authorise from RASP Vault

1. Open the instance and find Connect to Salesforce.
2. Paste the Consumer Key and Consumer Secret from the Connected App. The secret is stored encrypted and never shown again.
3. Choose Authorise. Salesforce asks you to sign in and approve access.
4. Sign in as your integration user. The backup can see exactly what that user can see — no more.

You return to the instance page, connected. To change credentials later, use Re-authorise Salesforce; leave the Consumer Secret blank to keep the stored one.

Permissions the integration user needs

• API Enabled, and read access to every object you want protected.
• View All Data and Query All Files to back up records, Files and Attachments the user does not own.
• View Setup and Configuration and Modify Metadata Through Metadata API Functions for metadata snapshots.

The instance page

Open any instance from Instances to see everything about that org in one place:

• Status, API budget used today, Last sync and whether Salesforce is connected.
• Objects — what is backed up, how many records and deletions, and anything excluded with its reason. See Objects, fields and formulas.
• Jobs — the latest runs for this instance.
• Files, attachments and documents — see Files and attachments.
• Configuration metadata — recent snapshots. See Metadata snapshots.

The buttons at the top run work on demand: Back up now, Back up files, Snapshot metadata and Refresh formulas.

API budget

Salesforce gives every org a daily allowance of API requests, shared by every integration. The API budget is the share RASP Vault may use — 10% by default, anything from 1% to 100%.

• RASP Vault reads the org's real allowance and remaining requests from Salesforce, and counts every call it makes.
• When the budget for the day is spent, or the org's overall remaining requests fall close to empty, the job pauses with status Paused — API limit.
• A paused job resumes by itself when budget is available again, from exactly where it stopped. Nothing is copied twice.

Backups

Running a backup

1. Open the instance from Instances.
2. Choose Back up now. The job is queued, and the background worker starts it within about a minute.
3. Follow progress in the instance's Jobs list or on Backups.

The first backup of an org copies everything and can take a long time on a large org — it pauses and resumes around the API budget on its own. Every later backup copies only what changed since the last one.

Kinds of backup job

Job statuses

Queued

Waiting for the worker, which checks every minute.

Running

Copying data now.

Paused — API limit

Waiting for API budget; resumes on its own at the time shown.

Paused — manual

Paused by an administrator.

Completed

Finished. Objects that Salesforce refused are listed with their reasons; everything else was copied.

Failed

Stopped by an error. The run details show why, and the next run continues from the last checkpoint.

Cancelled

Stopped by an administrator. Progress is kept, so a new run resumes rather than starting over.

Controlling a run

Backups lists every run, and each row carries the controls that suit its status. The table refreshes itself while a run is still going, so the status you see is the status it has.

Pause

On a queued or running job. It stops at the next checkpoint and waits; nothing already copied is lost.

Resume

On a paused job, whether an administrator paused it or the API budget did. It returns to the queue and carries on from its checkpoint.

Stop

Ends the run. Progress is kept, so the next run for that instance continues rather than starting over.

Run again

On a finished run: queues the same kind of job for the same instance. It is unavailable while that instance already has a run in progress, because only one runs at a time.

Run a backup, at the top of the page, queues a run for any active instance without leaving the list.

Schedules

Schedules run backups automatically. Super admins manage them on Schedules.

1. Choose New schedule and pick the instance.
2. Pick a frequency: Daily, or Weekly on the days you tick.
3. Set the time — hour, minute and timezone.
4. Choose Create schedule. The confirmation shows the next run.

• Edit on a schedule's row opens it for change — frequency, days, time, timezone — and carries a Paused switch: a paused schedule creates no runs until it is switched back on. The next run is worked out again from what you save.
• Delete removes the schedule after a confirmation. Backups it already queued or ran are kept; nothing runs on that rhythm again unless you create a new schedule.
• To back an instance up straight away, use Back up now on the instance page. If a job for that instance is already waiting, that is the job it starts; one paused by hand is resumed; one already running, or waiting out an API limit, is named as the reason to wait. Where the server allows it, the worker is started on the spot and the message says starting now; otherwise the job is queued and cron starts it within a minute.
• Times are wall-clock times in the timezone you choose. On the day clocks change, a time that does not exist runs at the next valid minute, and a time that happens twice runs once.
• A scheduled run starts the right kind of job by itself: an initial backup the first time, incremental afterwards.
• Pause stops future runs; a run already in progress continues. Resume starts the schedule again.
• If the worker was offline when runs were due, one catch-up run happens rather than a burst of missed ones.

Backup history

Backups lists the runs for a chosen date, filterable by instance and status. Today jumps back to the current day.

Select a run to open its details: the job type and status, when it started, finished or will resume, what it copied — objects, records inserted, updated and deleted, files — and its log, including any object Salesforce refused and why.

Objects, fields and formulas

Every object the integration user can query is discovered automatically on an instance's first run. Objects and fields added in Salesforce afterwards are picked up by the next full run, or by every run once Detect new metadata changes is switched on.

• Find an object on the instance page narrows the Objects list to names or labels containing what you type; the count beside the box says how many match.
• Excluded objects are listed under Excluded on the instance page with the reason — for example external objects (__x), whose rows live in another system.
• Skipped last run means Salesforce refused to query that object, with Salesforce's own reason shown. Every other object is still backed up; nothing is skipped silently.
• Overflow fields (+N) are fields beyond what fits in one database row. They are still backed up, in an overflow column, but cannot be filtered or sorted on through the API.
• Deleted records are kept and marked as deleted, never removed from the backup.
• Formulas recalculate in Salesforce without the record changing, so an ordinary backup does not see new formula values. Use Refresh formulas; the Formulas column shows when each object was last refreshed.

Choosing which objects are backed up

By default a backup takes everything the integration user can query. To narrow it, open the instance and choose Select Objects on the Objects card — the button appears once the org is authorised.

1. Tick the objects you want. The list is read from Salesforce itself, so objects never backed up are there too, each with its label and how many records the backup already holds.
2. Narrow the list with the search box. Select all and Deselect all act on what the search is showing, which is a quick way to take in a whole family at once — type __c for custom objects.
3. Save the selection. The next run keeps to it.

• The window has two tabs. Queryable Objects is what you choose from; Non-Queryable Objects lists what Salesforce will not let a backup read, with the reason against each one — not queryable, deprecated, or an external object (__x) whose rows live in another system. The search box filters both.
• Leaving an object out deletes nothing. Its table and its records stay in the backup and remain restorable; they simply stop being collected.
• Putting one back in collects it in full on the next run, because an incremental query of an object with no watermark would find nothing.

Building the tables before the first backup

Build tables, beside Select Objects, reads the org's schema and creates the backup tables now, rather than during the first run. It works a few objects at a time — one small request after another, with a progress bar — so a large org never depends on a single long request finishing. Each object's table is committed as it is built; an object Salesforce refuses to describe is listed as a problem and the rest carry on. Closing the page stops the build; opening the instance again picks it up where it stopped. The first backup then finds its tables ready and starts copying at once.

Files and metadata

Files and attachments

RASP Vault backs up everything Salesforce stores as a file or binary value:

• Every version of every Salesforce File (ContentVersion), including files posted to Chatter.
• Every legacy Attachment.
• Legacy Documents, Static Resources and every other binary field on a backed-up object.

Turning it on

On the instance page, switch on Back up files with every run in the Files, attachments and documents card, or run Back up files once. Documents and other binary fields follow their records, so run a record backup first.

Files are backed up the way records are: the first run copies every file, and each run after that copies only files that are new or have changed. A file whose content is identical to one already stored is kept once. The Show list beside it only filters the files listed on the page — it changes nothing about what is backed up.

Statuses

Stored

Downloaded and verified against the checksum or size Salesforce reports.

Waiting

Listed and queued for download.

Needs attention

Could not be stored after five attempts, or larger than the size limit (2 GB by default). The reason is shown on the file.

Downloading

Select a stored file to download it. Files edited in Salesforce keep their earlier contents, which stay downloadable. Downloads always save to disk rather than opening in the browser, and every download is recorded in the audit log.

Metadata snapshots

A metadata snapshot is a complete copy of your org's configuration at a point in time, retrieved through Salesforce's Metadata API: layouts, flows, Apex classes and triggers, Visualforce, Lightning components, profiles, permission sets, objects and fields, validation rules, reports, dashboards, email templates and more.

1. Take one now with Snapshot metadata on the instance page, or
2. switch on Snapshot with every run in the Configuration metadata card. Scheduled backups then take a new snapshot once a day.

What makes snapshots trustworthy

• Profiles and permission sets are complete. They are retrieved together with the objects, classes, pages, apps and flows they grant, which Salesforce requires for the permissions to be included.
• Large orgs just work. Retrieves that Salesforce rejects as too large are split and retried; retrieves still processing at Salesforce are collected by the next run.
• Unchanged files are stored once, so daily snapshots take little extra space.

Snapshot statuses

Complete

Every listed component was retrieved.

Partial

A retrieve failed; its error is in the warnings. Removals are not counted, because missing files may simply not have come back.

Listing / Retrieving

Still being taken.

Failed

Salesforce refused the snapshot, most often for missing permissions. The reason is shown.

Warnings are facts about single components — a type Salesforce would not list, or a component deleted while the snapshot ran. The rest of the snapshot is whole.

Browsing and comparing snapshots

Select a snapshot on the instance page to open it. Pick another snapshot from the list at the top at any time.

• Changes — what was added, changed and removed since the snapshot before, with before and after downloads for each file.
• Components — every component, filterable by type and name, with who last changed it and when.
• Files — every file, filterable by folder (such as classes or layouts) and by change.

Download zip saves the whole snapshot with package.xml at its root — ready to put under version control or deploy with Salesforce's own tools.

Restore

Restoring into Salesforce

Choose Restore in the menu, or Restore… on an instance page. Only a super admin can restore, because a restore writes into your live Salesforce org.

Pick the instance, then what you want back:

• Single record — one record, found by its name or Salesforce Id.
• Multiple records — several records of one object, picked from the backup.
• All records — every backed-up record of an object, or only the ones deleted from Salesforce.
• Metadata — layouts, flows, Apex and other configuration from a snapshot.

Before anything is written, a review says exactly what will happen, and you confirm it.

Restoring records

For each record, RASP Vault checks Salesforce at the moment of restoring:

• The record still exists — it is updated back to its backed-up values. Anything changed since the backup is overwritten.
• The record was deleted — it is created again. Salesforce never reuses an Id, so the restored record gets a new one. RASP Vault remembers which new Id replaced which old one, and every record restored afterwards that pointed at the old record — now or in a later restore — points at the new one.

Records are restored as the last backup saw them. Only fields Salesforce lets you set are written; formula fields, roll-ups and system fields such as Created Date are filled in by Salesforce itself.

Child records

Turn on Also restore child records to bring back the records that point at the ones you chose — the contacts and cases of an account, for example. RASP Vault asks Salesforce which objects point at yours and shows how many backed-up children each has. Tick the kinds you want, or Select all. Restored children are attached to the restored parent, even when the parent came back with a new Id.

Files and attachments

Turn on Also restore files and attachments to bring back the Salesforce Files and attachments backed up on the restored records. Only the newest version of each file is restored. A file that still exists in Salesforce is linked to a recreated record rather than uploaded again. Files over 25 MB cannot be restored through the Salesforce API; download them from the instance page and upload them by hand.

Restoring metadata

Choose a snapshot, then either Every component or Choose components and tick the ones you want. RASP Vault builds a deployment from the snapshot's files and Salesforce deploys it.

• Validate only checks the deployment — and runs tests where Salesforce requires them — without changing anything. Use it first in production.
• Undo everything if any component fails is always on in production orgs. In a sandbox you can turn it off to keep the components that did deploy.

Components that belong to an installed managed package are shown but cannot be chosen: only the package itself can change them. In production, Salesforce runs your org's tests whenever Apex is part of the deployment.

Following a restore

A restore runs in the background on the RASP Vault server, in short steps, so even a very large restore never times out. You can refresh the page, close it or sign out — the restore carries on. Open Restore again at any time and a restore that is still running is shown straight away.

While it runs you see:

• Progress — the percentage done and, once there is enough to go on, about how long is left. No estimate is shown while files are being restored, because how many files the records have is not known in advance.
• Running for, Started and Started by.
• What is being restored, with its options.
• Counts of records created and updated, files restored, and problems.
• What happened — every record, file and component with its result (created, updated, linked, skipped or failed) and why, 100 at a time. Choose Problems only to see just the failures.

If Salesforce asks RASP Vault to slow down, the restore waits for the time Salesforce asks for and then carries on by itself. Stop ends a restore; whatever was already restored stays in Salesforce.

The email when it finishes

When a restore finishes, the person who started it is emailed the result — completed successfully, completed with problems or failed — with what was restored, when it started and finished, how long it took, the counts, the first problems by Salesforce Id, and a link back to the full details. The email holds no backed-up data. A restore you stop yourself sends no email.

People and access

Managing users

Inviting someone

1. Open Users and choose Invite administrator.
2. Enter their email, name and role — Admin to run and view backups, or Super admin for full control.
3. Copy the invitation link from the message that appears and send it to them. It is shown once, works once and expires in 48 hours.

Disabling and enabling

Disable blocks an account immediately — any session it has open ends at once. Enable restores it. You cannot disable your own account.

The Last sign-in column shows when, where and from which address each person last signed in.

Resetting a password

Super admins see Reset password next to each active account on Users.

1. Choose Reset password next to the person's email address.
2. They receive an email with a link to choose a new password. It works once and expires in one hour.
3. They choose a new password, which signs them out everywhere else.

• The link goes only to the account's own address. The admin who asked never sees it.
• The current password keeps working until the new one is chosen, so an accidental reset locks nobody out.
• Sending another reset cancels the earlier link.

Sign-in history

The Sign-in history card on Users lists every sign-in and sign-out for your company's accounts, newest first.

Filter by account or result, or choose History on a user's row. History is kept for 365 days. Locations are looked up in a local database, so addresses are never sent to another service.

External API clients

Other systems — reporting tools, a Salesforce component, scripts — read backed-up data through the external API with a client token, separate from anyone's sign-in.

1. Open API clients and choose New client.
2. Name the client after the system that will use it.
3. Limit what it may read: tick Records and files, Configuration metadata or both, and choose the one instance it may read.
4. Choose Select Objects to narrow it further. The window lists what the backup actually holds for that instance, with how many records each object has; it opens with everything ticked, which means no restriction. Untick what the client should not see.
5. Choose Create client and copy the token. It is shown once and cannot be recovered.

Revoke stops a token working immediately, and cannot be undone. To replace a token, create a new client.

Using the external API

The API lives at https://rasp-vault.sf-backup.com/sfapi. Send the token in every request:

Authorization: Bearer rvk_…

Searching records

Requests name objects, fields and operators — never SQL.

POST /sfapi/v1/records/search
{
  "instanceId": "01J…",
  "object": "Account",
  "fields": ["Name", "Industry", "AnnualRevenue"],
  "filters": [
    { "field": "Industry", "operator": "equals", "value": "Banking" },
    { "field": "AnnualRevenue", "operator": "gte", "value": 1000000 }
  ],
  "orderBy": { "field": "Name", "direction": "asc" },
  "page": { "limit": 100 }
}

• Operators: equals, notEquals, in, notIn, gt, gte, lt, lte, between, contains, startsWith, endsWith, isNull, isNotNull.
• Paging: up to 500 records per page; pass page.cursor from one response to get the next.
• History: add "asOf": "2026-09-01T09:00:00Z" to see each record as it stood at that moment, and "includeDeleted": true to include deleted records.

Other endpoints

The full, machine-readable reference is at /sfapi/v1/openapi.json.

Settings and monitoring

Detecting new metadata

An org changes shape: a new custom object, a new field on Account, a new custom setting. A backup reads the schema when it first runs an instance, so by default those changes wait for the next full run.

Under Settings → Detect new metadata changes, switch on Back up new metadata automatically and every regular backup re-reads the schema — at most once a day:

• New fields become columns on the objects already backed up.
• New objects, including custom settings, get their table and are copied in full the first time they are seen.
• Each change is written to that run's log, and to the schema history for the object.

It applies to every instance in the company, and costs one Salesforce call per object on the day it runs, inside the instance's API budget as usual. Objects you have left out under Select Objects stay out — a selection is a decision, and automatic discovery does not overrule it.

Settings and monitoring

Configuring SMTP

RASP Vault sends password reset emails and failure alerts through your own SMTP server. Nothing that sends email works until SMTP is configured and tested.

1. Open Settings and choose Configure SMTP on the SMTP card.
2. Enter the server and choose the port — 587, 465, 25 or 2525 — and the security: STARTTLS (usually port 587), TLS (usually 465), or None, which is accepted only for a relay running on the RASP Vault server itself.
3. Enter the username and password from your mail provider. The password is stored encrypted and never shown again; leave it blank on a later edit to keep it.
4. Set the sender name and address that emails come from.
5. Choose Save and send test. RASP Vault connects, signs in and sends a test email to the address you gave.

Settings are saved only if the test succeeds — otherwise nothing changes and the message explains what the server said. The card then shows Ready.

• Send test sends another test to any address.
• Not tested means the stored settings have changed since their last successful test; email is blocked until a test passes.
• Remove SMTP deletes the settings and blocks email again.

Failure notifications

Add the addresses that should hear about problems under Settings → Failure notifications. When a backup fails or pauses, each address gets an email.

• Notifications name the instance, job and a sanitised reason — never any backed-up data.
• An instance failing repeatedly sends one alert an hour, not one per attempt.
• Notifications need SMTP configured and tested.

Your password

Change your own password under Settings → Your password: enter the current one and a new one of at least 12 characters. Every other session you have open is signed out.

Logs

Logs shows diagnostic detail from backups and the application. Filter by severity, instance, a date range and text the entry contains.

Credentials are removed before anything is written. When something goes wrong, error messages include a short reference such as (ref 01M2K…) — quote it and it finds the matching log entry.

Health check

Health Check in the menu answers one question: can RASP Vault do its work right now? It runs as the web user, the moment you open it, and reports a row per check — Pass, Check (working, but not as intended) or Fail (something is stopped).

• Only a super admin can open it, and nothing secret is reported: file paths and permissions, never contents, and never a password, token or key.
• No check can stop the page. One that cannot run becomes a row saying why, because a health page that dies on the first problem is no use on the day there is one.
• It complements tools/healthcheck.php, which the installer runs as root at deployment and which also verifies the uploaded files, the web server, ownership and the crontab.

How your data is protected

• Secrets encrypted at rest — Salesforce tokens and secrets, database passwords and the SMTP password, with AES-256-GCM and a key kept outside the database.
• Secrets never shown twice — screens report that a secret exists, never its value.
• Passwords hashed — sign-in passwords are stored only as bcrypt hashes; nobody, including RASP Vault, can read them.
• Company isolation — every request is checked against your company; another company's data cannot be named, let alone read.
• Audit trail — sign-ins, downloads, configuration changes and administrative actions are recorded with who, when and from where.
• Least access in Salesforce — the backup sees only what your integration user can, and you can revoke the Connected App at any time.

Help

Troubleshooting

Glossary

Instance

One Salesforce org and the database its backup is written to.

Integration user

The Salesforce user RASP Vault signs in as. The backup sees what this user can see.

Connected App

The Salesforce configuration that lets RASP Vault connect to your org through OAuth.

Job

One run of backup work for an instance.

API budget

The share of the org's daily API requests RASP Vault may use.

Snapshot

A complete copy of the org's configuration metadata at a point in time.

SMTP

The mail server RASP Vault sends emails through.

API client

A named token that lets another system read backed-up data.

Getting help

Can't find what you need? Contact us or write to admin@raspsys.com. Include the instance name, what you were doing, and any (ref …) code from the message you saw.