Skip to main content
Disaster Recovery & CDP

R1Soft Disk Safe Migration Without Breaking Backups

Move multi-terabyte Server Backup Manager (SBM) repositories across storage nodes. Preserve historical recovery points, SQLite delta journals, and block-tracking states with zero corruption.

11 min read
Updated: September 2026
Tested on SBM 6.x & 7.x Enterprise
migration / r1soft-disk-safe-sync
root@backup-manager-02:~# rsync -avzHAX --numeric-ids --progress /backups/disk-safes/srv-node-42/ target-sbm:/backups/disk-safes/srv-node-42/
transferred 3.84 TB in 04:22:15 (Extended attributes & sparse blocks preserved)
root@backup-manager-02:~# chown -R cdp:cdp /backups/disk-safes/srv-node-42/
root@backup-manager-02:~# chmod -R 750 /backups/disk-safes/srv-node-42/
root@backup-manager-02:~# serverbackup-manager --attach-disk-safe --path /backups/disk-safes/srv-node-42/
Disk Safe attached. 184 recovery points verified healthy. Zero rescan required.
root@backup-manager-02:~#
Quick Answer / Executive Summary

To migrate an R1Soft Disk Safe without breaking backups: 1) Disable backup policies and gracefully close the Disk Safe on the source SBM; 2) Use rsync -avzHAX --numeric-ids to preserve sparse file allocations and extended attributes; 3) Reassign user ownership to cdp:cdp on the destination host; 4) Attach the repository via the web UI; and 5) Execute an alternate-path test file restore before enabling scheduled policies.

Understanding R1Soft Disk Safe Architecture

An R1Soft (Server Backup Manager) Disk Safe is not a collection of plain files. It is a proprietary block-level virtual disk repository consisting of an embedded SQLite metadata database, write-ahead transaction logs, encryption keystores, and sparse multi-gigabyte delta allocation blocks.

When hosting providers upgrade backup hardware, split workloads across regional clusters, or expand dedicated SAN/NAS arrays, migrating Disk Safes incorrectly can corrupt the internal SQLite journal. This results in the dreaded Disk Safe is damaged or locked error, breaking months of historical compliance backups and forcing a slow, resource-heavy full rescan of client production servers.

Integrity First
Pre-Migration Audit

Run SQLite header validation to ensure source repositories have zero corruption flags.

Attributes
Sparse & Hardlinks

Preserve sparse file holes and extended attributes (-aHAX) to prevent storage bloat.

Re-Attachment
Lock-Free Attach

Graceful detachment on source and ownership alignment (cdp:cdp) on the destination server.

Step-by-Step Runbook for Zero-Corruption Disk Safe Migration

Step 1: Pause Policies & Close Disk Safe Gracefully

Never copy a Disk Safe while a backup policy is running or in a queued state. In the source SBM web console: navigate to Policy, disable the associated policy, go to Disk Safes, select the target, and click Actions >> Close Disk Safe. This flushes active memory journals to disk and removes runtime file locks.

# Confirm no active processes hold open file handles to the Disk Safe
lsof +D /backups/disk-safes/web-server-01/

Step 2: Transfer Data with Sparse & Attribute Preservation

R1Soft repositories make heavy use of sparse files and POSIX extended attributes. Standard scp or unconfigured rsync will expand sparse zeros into physical bytes, needlessly ballooning a 1 TB Disk Safe into 4 TB of allocated disk space. Use the exact flags below:

# Enterprise rsync command for R1Soft Disk Safes
rsync -avzHAX --numeric-ids --progress \
  /backups/disk-safes/web-server-01/ root@DEST_IP:/backups/disk-safes/web-server-01/

Step 3: Fix Daemon Ownership on the Destination Host

The R1Soft Server Backup Manager daemon runs under the unprivileged service user cdp (or r1soft depending on OS package). If the transferred files remain owned by root, the manager cannot read database journals.

chown -R cdp:cdp /backups/disk-safes/web-server-01/
chmod -R 750 /backups/disk-safes/web-server-01/

Step 4: Attach Existing Disk Safe & Execute Test Restore

In the destination SBM web interface, click Attach Existing Disk Safe, provide the directory path, and let SBM auto-discover the metadata. Once attached, open Recovery Points, browse a snapshot from 30 days prior, and perform an alternate-path test restore of a small text file (such as /etc/hosts). Once verified, reassign the backup policy.

Pre-Flight & Post-Migration Health Checklist

SBM Version Parity: Ensure the target Backup Manager runs the same or newer minor release of R1Soft Server Backup Manager. SBM supports automatic forward schema upgrades, but never backwards downgrades.
Filesystem Feature Support: Verify the target partition is formatted with an enterprise filesystem supporting user extended attributes and POSIX ACLs (XFS or ext4 recommended).
Disk Headroom: Confirm at least 20% free storage headroom above the total Disk Safe size to accommodate SQLite temporary compilation journals during high-volume backups.
Kernel Driver Continuity: Ensure the client machine agent key is trusted on the destination SBM (serverbackup-setup --get-key https://target-sbm-ip) so incremental delta replication continues without full scans.
Infrastructure Support

Migrate Your Backup Repositories With Complete Peace of Mind

Protect historical recovery snapshots and compliance archives with experienced systems engineers executing your R1Soft storage transfers.