Loading...
Loading...
This article covers vbsf-export, a standalone utility that exports Salesforce backup data from a Veeam Backup for Salesforce deployment to cloud storage or to a local folder. The exported files can then be used, for example, with the Data Import feature of Veeam Data Cloud for Salesforce to migrate the backup history to the cloud.
With vbsf-export, backup data is exported from the PostgreSQL database managed by Veeam Backup for Salesforce to Azure Blob Storage, Amazon S3, or a local folder. The utility is distributed separately from Veeam Backup for Salesforce and is compatible with version 3.2.0 or later.
One export target must be selected. Only one target can be configured per run, and Azure, AWS S3, and local targets cannot be combined: For Azure, the Blob container, storage account name, and access key are required. For AWS S3, the bucket, region, access key ID, and secret access key are required. For a local folder, only a writable directory path is required. The directory is created if it does not already exist. The Veeam Backup for Salesforce deployment must be version 3.2.0 or later; vbsf-export is not compatible with earlier versions. Java 21 must be available on the host where the utility will run.Note: When the utility is installed from the package, the Java runtime is installed as a dependency. Network connectivity from the host to the backup PostgreSQL database and the export destination must be confirmed (including network, DNS, firewall, and proxy configurations, as applicable). Data archival policies must be paused, and a fresh backup must be run to capture the latest state before exporting. The backup database connection details (JDBC URL, username, and password) and the 18-character Salesforce.org ID must be available.
To avoid latency and connectivity issues, the vbsf-export utility should be deployed and run on the Postgres DB host, which is typically the Veeam Backup for Salesforce host itself. When a cloud target is used, the script will stream exported data directly to cloud storage via a TLS connection. Red Hat, AlmaLinux, Rocky, and Oracle | Version 8
All parameters can be passed as CLI flags (--property=value) or as uppercase environment variables. When the utility is run with no arguments, -h, or --help, the full parameter reference is printed. For validation, --test_run=true can be added to check connectivity and show which tables match the configured filters, without exporting any data. By default, only the start and finish statuses are shown in the console; details are written to the log files specified by the log_output parameter (vbsf-export.log and debug/vbsf-export.log). To stream full progress to the console instead, --follow (-f) can be added. To also include the history restore points for an object, __h can be added to the table filter. For example, --export_table_filter='^account(__h)?$' exports the Account object and its history. Note that Salesforce object names are mapped to lowercase table names in the backup database. When exporting data for later import into Veeam Data Cloud for Salesforce, --sf_object_name=true should be used. Resuming an Interrupted Export If an export is interrupted, running the same command again continues into the same folder, and tables that have already been completed are skipped. Incomplete files left behind by the interrupted run are discarded, and those tables are exported again. Progress is tracked in a vbsf-export-status.txt file inside the export folder. Because a completed export is not rerun, this file must be deleted before the same command can be run again to produce a fresh export. Example: Export to Azure Blob Storage In the following example, only the Account object's data, changed on or after June 1, 2025, is exported to Azure Blob Storage: java -jar vbsf-export.jar \ --jdbc_url=jdbc:postgresql://localhost:5432/vbsf_application \ --jdbc_username=vbsf --jdbc_password=*** \ --sf_org_id=00D000000000000EAA \ --azure_account_name=mystorageaccount --azure_access_key=*** \ --azure_container_name=vbsf-export \ --log_output=/var/log/vbsf/vbsf-export \ --export_table_filter='^account$' \ --filter="vsf_last_modified_date >= '2025-06-01 00:00:00+00'" Example: Export to a Local Folder In the following example, the same data is exported to a folder on the local host: java -jar vbsf-export.jar \ --jdbc_url=jdbc:postgresql://localhost:5432/vbsf_application \ --jdbc_username=vbsf --jdbc_password=*** \ --sf_org_id=00D000000000000EAA \ --local_dir=/var/vbsf-export \ --log_output=/var/log/vbsf/vbsf-export \ --export_table_filter='^account$' \ --filter="vsf_last_modified_date >= '2025-06-01 00:00:00+00'"
Salesforce object record data (current state and history restore points) is exported from the backup PostgreSQL database to Azure Blob Storage, Amazon S3, or a local folder. Everything can be exported, or the run can be limited to specific Salesforce objects by matching table names using a regular expression (by default, all tables are exported). Only a date range can be exported instead of the full history: a SQL condition (for example, "modified on or after a given date") can be applied to all exported tables, or overridden for a specific table. Output can be produced as plain CSV, GZIP, ZIP, or password-protected ZIP, with optional row-count or size-based file splitting. An interrupted export can be resumed in the same export folder, skipping the tables that have already been completed. A test-run mode is available to validate the configuration before exporting real data.
Only Salesforce object record data is exported; binary data (Files, Attachments) and metadata export are not supported. Data is not decrypted, so encrypted fields are excluded by default. If the decrypted data is required (for example, to perform Data Import into Veeam Data Cloud for Salesforce), the fields must be decrypted beforehand. Only one storage target can be used per run. Azure, AWS S3, and local targets cannot be combined. When a cloud target is used, data is streamed directly to cloud storage, so a stable connection from the export host to the storage endpoint is required for the entire run. If a column referenced by a row filter does not exist for a table (or causes a type mismatch), that table is skipped with a warning in the log, and the remainder of the export continues.
Instructions for preparing and loading the exported files are provided in KB4878.
Veeam Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.