How to Migrate Disk Safe from One R1Soft Backup Manager to Another

Migrating an R1Soft Disk Safe between Backup Manager servers is a critical storage operation. Whether you are decommissioning legacy hardware, expanding dedicated SAN/NAS storage volumes, or splitting backup workloads across regional clusters, transferring multi-terabyte Disk Safes requires strict synchronization protocols.

Critical Safety Warning: Moving a Disk Safe is not a simple file transfer. The destination Backup Manager must recognize internal block-level delta metadata, volume UUIDs, and encryption headers. Do not remove or format the original source backup storage until you have verified recovery points and performed a successful test restore on the destination manager.

At a Glance

1. Audit source Disk Safe health and verify there are no active corruption flags.
2. Disable all scheduled backup policies referencing the target Disk Safe.
3. Close the Disk Safe in the source R1Soft web interface.
4. Synchronize the Disk Safe directory to the destination server using rsync with attribute preservation.
5. Set correct Linux user ownership (cdp:cdp or r1soft:r1soft) on the destination host.
6. Attach the existing Disk Safe in the destination Backup Manager web interface.
7. Assign the Disk Safe to the protected machine and policy.
8. Perform a test file restoration to confirm data readability.
9. Resume scheduled backup policies.

---

Prerequisites

Before starting the migration, verify the following prerequisites:

• Root SSH access on both the source and destination Backup Manager servers.
• Identical or newer R1Soft Server Backup Manager version running on the destination server.
• Destination filesystem formatted with an enterprise filesystem supporting sparse files and extended attributes (XFS or ext4 recommended).
• Network bandwidth and sufficient free disk storage on the destination volume (at least 20% headroom above Disk Safe size).
• Target backup agent installed and registered on the destination Backup Manager.
• If the Disk Safe is AES-256 encrypted, ensure you have the original passphrase or encryption key file available.

---

Step 1: Pre-Migration Health Check and Path Verification

Log in to the source Backup Manager and locate the exact filesystem path of the Disk Safe you intend to move.

In the web interface:

1. Navigate to Disk Safes.
2. Select the target Disk Safe and inspect the Path property (e.g., /backup/disk-safes/web-server-01/).
3. Click Actions >> Verify Disk Safe to ensure the SQLite header metadata and delta block journals are completely healthy before copying.

Check disk usage on the source host:

# Check size of the Disk Safe directory
du -sh /backup/disk-safes/web-server-01/

---

Step 2: Pause Backup Policies and Close the Disk Safe

To prevent data corruption caused by mid-transfer block writes, you must stop all incoming replication tasks:

1. In the source web interface, go to Policy.
2. Locate any policy attached to the Disk Safe and click Actions >> Disable Policy.
3. Go to Disk Safes, select the Disk Safe, and click Actions >> Close Disk Safe (or detach it).

On the source server CLI, confirm no active CDP processes hold open file handles to the Disk Safe directory:

lsof +D /backup/disk-safes/web-server-01/

If no processes return, the Disk Safe is in a consistent, idle state ready for migration.

---

Step 3: Transfer Disk Safe Data Preserving Attributes

Use rsync to transfer the Disk Safe directory to the destination server.

Important: Always use -aHAX flags to preserve sparse files, hardlinks, and extended attributes.

Run the initial data synchronization from the source server:

# Execute initial rsync synchronization
rsync -avzHAX --numeric-ids --progress /backup/disk-safes/web-server-01/ root@DESTINATION_SERVER_IP:/backup/disk-safes/web-server-01/

Explanation of flags:

• -a: Archive mode (preserves timestamps, permissions, symlinks).
• -v: Verbose output.
• -z: Compress file data during network transfer.
• -H: Preserve hard links.
• -A: Preserve Access Control Lists (ACLs).
• -X: Preserve extended attributes.
• --numeric-ids: Preserve numeric user and group IDs without mapping to local system accounts.

For very large multi-terabyte Disk Safes, run an initial sync while backups continue, and then perform a quick differential final sync after closing the Disk Safe in Step 2.

---

Step 4: Validate Destination File Ownership and Permissions

Log in to the destination Backup Manager server via SSH. Verify that the files were copied intact and set proper ownership for the R1Soft system daemon:

# Identify the user running the R1Soft daemon (usually cdp or r1soft)
ps aux | grep -i cdp-server

# Update ownership across the entire migrated Disk Safe directory
chown -R cdp:cdp /backup/disk-safes/web-server-01/
# or on systems using r1soft user:
chown -R r1soft:r1soft /backup/disk-safes/web-server-01/

# Set secure directory permissions
chmod -R 750 /backup/disk-safes/web-server-01/

---

Step 5: Attach the Existing Disk Safe in Destination Web UI

Log in to the destination R1Soft Backup Manager web console:

1. Click on Disk Safes in the left navigation menu.
2. In the top toolbar, click Attach Existing Disk Safe.
3. In the dialog box:
   • Path: Enter the destination directory path (e.g., /backup/disk-safes/web-server-01/).
   • If the path contains valid metadata, R1Soft auto-detects the Disk Safe identifier.
4. Click Attach.

The Disk Safe will appear in the Disk Safes list with its original name, protected device mappings, and recovery point count.

---

Step 6: Reassign Disk Safe to Policy and Verify Recovery Points

1. In the destination Backup Manager, navigate to Protected Machines.
2. If the protected machine has not yet been registered on this Backup Manager, add it via Add Machine and enter the client server’s hostname and IP.
3. Navigate to Disk Safes, select the attached Disk Safe, and ensure it is assigned to the correct Protected Machine.
4. Click Recovery Points icon to inspect historical snapshots. Verify that all historical dates and snapshots appear intact.

---

Step 7: Perform a Test Restore to Confirm Data Integrity

Before placing the Disk Safe back into active scheduled backup rotation, perform a non-destructive test file restoration:

1. Open Recovery Points on the destination Backup Manager.
2. Select an older recovery point and click Browse Files.
3. Select a safe, non-critical file (e.g., /etc/hosts or /etc/resolv.conf).
4. Choose Restore to Alternate Location (e.g., /tmp/migration_test/).
5. Run the restore and verify that the file arrives on the client machine with matching checksums.

---

Step 8: Resume Scheduled Backup Policies

Once the test restore succeeds:

1. Create or enable the backup Policy on the destination Backup Manager.
2. Run a manual on-demand backup job: Actions >> Run Now.
3. Monitor the task log to ensure block delta calculation completes without full rescan alerts.
4. Keep the source Disk Safe archived for at least 7 days before decommissioning.

---

Troubleshooting

Problem: “Disk Safe is already in use by another Backup Manager instance”

Possible cause: The Disk Safe metadata lock file (DiskSafe.lock or internal SQLite journal lock) was not released because the source manager was not closed gracefully.

Check:

ls -la /backup/disk-safes/web-server-01/

Solution: Ensure the source Backup Manager has closed or deleted its registration of the Disk Safe. If the source server is permanently decommissioned, verify no cdp-server process holds open handles and restart the destination cdp-server daemon.

Problem: “Permission Denied when reading DiskSafe .db files”

Possible cause: The migrated files are owned by root instead of the cdp or r1soft service user.

Check:

ls -la /backup/disk-safes/web-server-01/metadata/

Solution: Reapply recursive ownership to the R1Soft daemon user:

chown -R cdp:cdp /backup/disk-safes/web-server-01/

Problem: “Rsync error: some files/attrs were not transferred (code 23)”

Possible cause: The destination storage filesystem does not support extended attributes (XATTR) or ACLs, or SELinux context attributes failed to transfer.

Check:

mount | grep /backup

Solution: Ensure the destination partition is mounted with user_xattr and acl options enabled in /etc/fstab.

---

Verify the Configuration

To verify that the Disk Safe migration is 100% complete and operational:

1. Verify Disk Safe State: Run a complete verification scan from the web console: Disk Safes >> Actions >> Verify Disk Safe.
2. Verify Recovery Point Traversal: Browse files across at least three distinct historical recovery points.
3. Verify Delta Replication: Run a scheduled backup policy and confirm that only new delta blocks are replicated without triggering an uncompressed full backup.

---

Production Checklist

• Verified source Disk Safe health before migration.
• Disabled all backup policies and closed Disk Safe on source manager.
• Transferred files using rsync -avzHAX --numeric-ids.
• Verified disk capacity on destination volume (df -h).
• Set destination directory ownership to cdp:cdp.
• Attached Disk Safe successfully in destination web UI.
• Executed non-destructive test file restore to alternate directory.
• Ran on-demand delta backup job and confirmed normal replication.
• Retained source Disk Safe backup for safety buffer period.

---

Frequently Asked Questions

Will moving a Disk Safe force a full, slow re-scan of the client server?

No. Because R1Soft tracks block allocations through the kernel driver (cdp-2.6.x / sbm-agent), as long as the Disk Safe metadata remains intact, the destination Backup Manager will continue incremental delta replication seamlessly.

Can I migrate a Disk Safe between different major R1Soft versions?

You can migrate from older versions to newer versions (e.g., R1Soft 6.x to 7.x), as the destination manager will automatically upgrade the internal SQLite schema. However, you cannot migrate a Disk Safe backwards from a newer version to an older release.

How long does a multi-terabyte Disk Safe migration take?

Transfer speed depends entirely on network throughput and storage I/O. Over a 10 Gbps LAN connection, a 2 TB Disk Safe typically syncs in approximately 30–45 minutes.

---

Related Guides & Services

• How to Restore a Server Backup Using R1Soft
• How to Install SSL on R1Soft Backup Manager Using Certbot
• Zero-Downtime Server Migration Services
• Enterprise Server Backup Management

---

Planning an Enterprise Backup Storage Migration?

Migrating multi-terabyte backup repositories across data centers requires careful planning to prevent data loss. If you need systems engineers to manage your backup infrastructure migrations, reach out to our team.

Contact Us