Veeam Data Cloud for Salesforce: End-to-End Setup Guide

Procedural Medium Veeam Data Cloud Salesforce

Salesforce has a native recycle bin, but deleted records only live there for 15 days. After that they are gone permanently unless you have a backup. Veeam Data Cloud for Salesforce is the BaaS version of Veeam's Salesforce protection -- no appliance to deploy, no Linux VM to manage, no storage to provision. You connect your org, configure the policy, and the first backup runs. This article walks the full setup from account access through to a verified first backup.

What You're Working With

Veeam Data Cloud for Salesforce is a SaaS backup service. The infrastructure -- compute, storage, and the backup database -- runs in Microsoft Azure and is fully managed by Veeam. You access everything through a web console at cloud.veeam.com. There is nothing to install, no agent to deploy into Salesforce, and no infrastructure to size or maintain on your end.

The product protects three categories of Salesforce content:

Backup runs incrementally after the initial full. Veeam uses Salesforce's API to compare the current state of each object against the last known state. Only changed records are backed up, which keeps API consumption reasonable and keeps backup windows tight. For objects with more than 20 million records, Veeam starts a separate session per object to keep initial backup performance manageable.

Before You Start

• ✓A Veeam Data Cloud account. You can sign up at cloud.veeam.com. If your organization already uses VDC for Microsoft 365 or Azure, you use the same organization -- Salesforce is added as a workload alongside the others.
• ✓An active Salesforce org on Enterprise, Unlimited, Performance, Developer, or Professional (with API add-on) edition. Production, sandbox, and developer orgs are all supported.
• ✓A Salesforce user account to use as the backup service account. This must be a Standard User with a Salesforce license type. Free Integration Users cannot perform backup or restore operations. The account needs full read and modify permissions on the objects you want to protect.
• ✓The Salesforce user account language must be set to English in both the locale settings and the account language settings. This is required for the error handler to work correctly.
• ✓Your VDC account must have the Salesforce:Administrator or Salesforce:BackupOperator role assigned to the user who will add and configure tenants.
• ✓The Veeam Data Cloud External Client App managed package must be installed in each Salesforce org you want to protect. Install it from Salesforce AppExchange before attempting to add the tenant in VDC. This is required because Salesforce restricted uninstalled connected app access in late 2025. Without this package installed, the VDC wizard will fail at the authorization step with an error stating that the external client app is not installed in the org.

Step 1 -- Sign In and Locate the Salesforce Section

1. 1Navigate to cloud.veeam.com and sign in with your Veeam Data Cloud credentials.
2. 2From the left navigation panel, select Salesforce. If this is your first time using Salesforce protection, the page will prompt you to add your first tenant.
3. 3If you need to invite additional team members before setting up, go to Users and Roles first and assign the Salesforce:Administrator role to anyone who will manage backup policies, and Salesforce:BackupOperator to anyone who only needs to run and monitor jobs. Get RBAC sorted before you start adding tenants.

Step 2 -- Add Your Salesforce Tenant

Each Salesforce org -- production, sandbox, or developer -- is a separate tenant in VDC. You can protect multiple orgs from the same VDC organization. Adding a tenant walks you through a short wizard.

1. 1Click Add Tenant. The Add Salesforce Tenant wizard opens.
2. 2Specify a display name for this tenant. Choose something that makes it obvious which org this is -- something like ACME Corp Production or Customer Sandbox. You will see this name everywhere in the VDC console.
3. 3Select the backup storage region. This is the Microsoft Azure region where VDC will store your Salesforce backup data. Choose a region close to your Salesforce org's data center or one that satisfies your data residency requirements. AMER options include Canada Central, East US, South Central US, and West US. APJ includes Australia East. EMEA regions are also available. Once you set this for your first Salesforce tenant, all subsequent tenants in the same VDC organization use the same region. If you need a different region later, contact Veeam Support before adding the tenant.
4. 4Select the login type: Production (uses login.salesforce.com), Sandbox (uses test.salesforce.com), or Custom (specify your own domain URL). Most orgs use Production or Sandbox. Select the one that matches the type of org you are connecting.
5. 5Click Sign in with Salesforce. You will be redirected to the Salesforce authentication page. Log in with the credentials of the dedicated service account you prepared in the prerequisites. After authenticating, you are redirected back to the VDC wizard.
6. 6Configure API limits. Salesforce limits the total number of API requests per 24-hour window. If your org uses other integrations or ETL processes that also consume API calls, set thresholds here so VDC does not crowd out other applications. VDC checks remaining API capacity before each session and will fail gracefully rather than consume your entire API budget. For most orgs starting out, the defaults are fine -- revisit this once you have a sense of your actual API consumption patterns.
7. 7Verify permissions. Click Verify permissions. VDC checks whether the connected service account has all the permissions required for backup and restore. If anything is missing, the wizard tells you exactly what to grant. You can also enable Automatically assign permissions to let VDC assign the required permissions directly -- the service account needs System Administrator profile or a profile with the Manage Users permission for this to work. Fix any gaps before proceeding.
8. 8Click Finish. VDC adds the tenant and automatically creates a default backup policy for it.

Step 3 -- Configure the Backup Policy

The default policy is created automatically when you add the tenant, but its defaults are conservative. You should review and adjust it before the first backup runs.

Navigate to Salesforce > Backup Policies and select the policy for the tenant you just added. Click Edit.

Schedule

The default schedule runs once daily. For most production orgs, you will want something more frequent. VDC supports schedules down to the object level, so you can run the full policy daily but configure specific high-value objects -- Opportunities, Cases, custom transaction objects -- to back up every few hours. In the policy editor, find the schedule section and set the global frequency first, then use the per-object overrides for anything that needs a tighter RPO.

Object Scope

By default the policy is configured to back up all objects in the org, with Automatically add new objects and Automatically add new fields on objects both enabled. This is the right choice for most deployments -- if someone creates a new custom object or adds a field and you are not auto-discovering, you will have gaps in your backup coverage without knowing it.

If you want to exclude specific objects, you can do so here. Objects worth reviewing for exclusion are things like audit log objects, or very high-volume transactional objects that do not need retention history. Be deliberate about exclusions. It is easy to forget what you excluded six months later when you need to restore something.

Encryption

Backup data is encrypted at rest by default using Veeam-managed keys. This covers most organizations. If you have regulatory requirements to control your own keys, VDC supports AWS KMS BYOK (Bring Your Own Key) -- you supply the AWS KMS key and VDC uses it for all encryption operations. The encryption setting is configured in the policy editor under the Security section. If you enable BYOK, make sure your IAM policies grant VDC the necessary permissions to use the key; the help center lists the exact operations required.

Retention

Default retention keeps restore points for a set number of days. Adjust this to match your compliance requirements. Most organizations working toward HIPAA or SOX alignment need at least 6 years of retention for certain record types -- that is what the archival policy is for, which is a separate configuration covered later in this article.

Step 4 -- Run and Verify the First Backup

With the policy configured, trigger the first backup manually rather than waiting for the scheduled run. This gives you immediate feedback and surfaces any permission or API issues before the scheduled window.

1. 1In the Backup Policies view, select the policy for your tenant and click Run Now.
2. 2Navigate to Activity > Backup Sessions to watch the session in progress. The first backup is always a full -- VDC creates a separate session for each category: one for data, one for files, one for metadata. These run in parallel.
3. 3For large orgs, the initial full backup takes time. Objects with more than 20 million records get their own dedicated session. Do not interrupt the session. If it fails partway through, the next run will pick up where the data session left off rather than starting completely over.
4. 4When the session completes, check the Salesforce Dashboard view. You should see your tenant listed with a green protection status and a last backup timestamp. If any objects show warnings, click into the session log for that session to see which objects had issues and why.

Step 5 -- Configure Notifications

VDC supports email notifications for backup job results, restore completions, Salesforce connection issues, and data change alerts. The data change alert is especially useful -- you set a threshold percentage, and if VDC detects a change in the volume of records above that threshold (mass deletion, a bad data loader import, a runaway process), it fires an alert immediately rather than waiting for you to notice at review time.

1. 1In the VDC console, navigate to the Salesforce section and open your tenant settings.
2. 2Find the Notifications section and add the email addresses that should receive alerts. Use a shared team mailbox or distribution list rather than an individual address -- this keeps alerts visible if that person is out.
3. 3Enable the Data Change alert and set a reasonable threshold. A threshold of 10% is a common starting point for most orgs. Tune it down if you have high-volume workflows that legitimately process large batches, or up if your org has relatively stable record counts. The goal is to catch accidental mass deletions, not every normal data operation.
4. 4Enable Backup job alerts so that failures do not go unnoticed. The default behavior of most people is to check the console periodically -- alerts mean failures come to you instead of waiting to be discovered.

Step 6 -- Lock Down Access with RBAC

VDC supports role-based access control at the Salesforce workload level. For organizations with separate IT and Salesforce admin teams, this matters -- you probably do not want your Salesforce developers having access to restore or delete backup data, and you probably do not want your backup admins modifying Salesforce org settings.

Custom roles are created under Users and Roles > Roles > Create Role. You select exactly which operations are permitted. This is the right path for MSPs managing multiple customer tenants -- a customer's team can be given access to their own tenant's restore operations without being able to see or touch any other customer's data.

Step 7 -- Understand Your Restore Options Before You Need Them

The restore options in VDC for Salesforce are one of the product's strongest areas. There are four distinct recovery paths, and knowing which one to use before you are in an incident situation saves a lot of time and stress.

All restore operations can target the same org or a different org -- including a sandbox. This makes VDC useful beyond just disaster recovery. You can restore a snapshot of production data into a developer sandbox for testing, or seed a QA sandbox with fresh production data, using the same backup that protects your production org.

Step 8 -- Configure an Archival Policy (Optional but Worth Knowing)

The archival policy is separate from the backup policy and serves a different purpose. Where the backup policy protects your current Salesforce data so you can recover it, the archival policy is about moving old or inactive data out of Salesforce storage while keeping it accessible for compliance and analysis.

When archival runs, VDC copies records that match the archival criteria (typically records older than a defined age, or records in a specific status) out of Salesforce and into the VDC backup storage. Those records are then deleted from the live Salesforce org, freeing up Salesforce data storage -- which, if you have ever received a Salesforce storage warning, you know is not cheap to expand.

The archived records remain searchable and retrievable from within VDC. If a compliance audit needs data from three years ago, you can query and export it directly from the VDC console without needing to restore it into Salesforce first.

Archival policies are configured under Salesforce > Archival Policies. You define the target objects, the age or status criteria, and the schedule. Do not configure archival policies casually -- deleting records from production, even with good intent, has downstream effects. Validate the criteria against a sandbox before enabling archival on production.

Day-Two: Monitoring What Matters

Once setup is complete, two views in the VDC console are worth checking regularly.

Salesforce Dashboard gives you a per-tenant summary: last backup time, protection status, number of objects covered, and recent session results. If the dashboard shows anything other than green for a tenant you care about, that is where you start.

Activity > Backup Sessions gives you the full session history with per-session logs. For compliance purposes, these logs are your evidence that backups are running on schedule. If your organization needs to demonstrate backup activity to an auditor (SOC 2, HIPAA), the session logs are what you point to. Export and archive them on a schedule that matches your retention requirements -- do not rely solely on the VDC console's internal retention to preserve your compliance evidence.

Activity > Audit Logs records every action taken by every user in the VDC console -- who ran what restore, who changed which policy setting, who added or removed a user. This is the access control evidence trail your auditors will want.

---