Migrate R1Soft disk safes to a new storage volume

Every R1Soft Server Backup Manager outgrows its first storage layout eventually. The 4 TB volume you sized in year one fills up by year three, the spinning disks under the SBM start dragging merge windows past breakfast, or you finally splice in a JBOD and need to move terabytes of disk safes onto it without throwing away years of recovery points.

This guide moves disk safes from one volume to another on the same SBM host. End-to-end on a busy SBM with 8 TB of safes: 6–14 hours, most of it rsync. The web UI stays up; agents reconnect when the SBM comes back; recovery point history is preserved.

What's actually on disk

An R1Soft disk safe is a directory, not a file. On a stock install the path looks like:

/var/lib/r1soft-volumes/<volume-id>/<disk-safe-id>/
├── DiskSafe.cdp        # metadata
├── BlockStore/         # delta data, large and sparse
├── ChainStore/         # block chain index
└── Recovery Points/    # per-recovery-point manifests

The SBM tracks two things you have to keep aligned: volumes (named storage targets with a filesystem path) and disk safes (the directories above, attached to one volume). The migration plan is to register a new volume, copy each safe to it with the directory layout intact, and re-attach the safes from the new path. The SBM is happy as long as the directory contents survive the move byte-for-byte.

Prerequisites

• Root on the SBM host
• A new block device or LVM volume formatted with a sparse-file-capable filesystem (xfs, ext4, zfs) mounted at e.g. /mnt/r1soft-new
• Enough free space on the new volume to hold every safe you plan to move, plus 10% headroom for the next merge cycle
• SBM 6.16 or newer (older versions have a known issue where re-attached safes don't reconcile chain indexes — upgrade first; see R1Soft sizing for the storage math)
• A maintenance window long enough for the final delta sync (usually 30–60 minutes per TB on local NVMe)

Step 1 — Prepare the new volume

Mount the new volume and create the R1Soft directory tree with the right ownership:

mkdir -p /mnt/r1soft-new/r1soft-volumes
chown cdp:cdp /mnt/r1soft-new/r1soft-volumes
chmod 700 /mnt/r1soft-new/r1soft-volumes

The cdp user owns every file the SBM writes. If the new volume lives on XFS, mount with noatime,inode64,nodiratime. On ZFS use a dedicated dataset with recordsize=128K and atime=off — the default recordsize=128K lines up with R1Soft's block size and avoids write amplification on the BlockStore.

In the SBM web UI go to Configuration → Volumes → New and add the new path. Give it a name you can tell apart from the old volume (e.g. nvme-pool-2). Don't attach any disk safes yet.

Step 2 — Pause policies, not the SBM

You want agents to keep heartbeating while the bulk copy runs, but you do not want new recovery points landing on a safe you're about to move. From the SBM web UI:

1. Policies → select all → Edit → Disable schedule. Leaves the policy intact; just stops new runs.
2. Recovery Point Limits → Disable cleanup. Prevents the merger from rewriting blocks under you mid-copy.

Confirm nothing is running:

curl -ks https://localhost:8443/apiapp/api/v1/Task | jq '.tasks[] | select(.state=="RUNNING") | .id'

If anything is in flight, wait for it. Killing a running merge task corrupts the chain index — there is no shortcut here.

Step 3 — Bulk copy with rsync

This is the long step. Run it while policies are still disabled but before you detach the safes, so the SBM doesn't notice the disk safe directories are being read.

rsync -aHAXS --info=progress2 --no-inc-recursive \
  /var/lib/r1soft-volumes/<old-volume-id>/ \
  /mnt/r1soft-new/r1soft-volumes/<old-volume-id>/

What each flag does and why it matters:

• -a archive mode (recursive, preserves permissions, timestamps, symlinks)
• -H preserve hardlinks — the ChainStore uses them
• -A preserve ACLs (R1Soft sets a few)
• -X preserve extended attributes
• -S preserve sparse files — without this, BlockStore files balloon by 5–10x on the destination
• --no-inc-recursive shows accurate progress on big trees

Skip --checksum. The blocks haven't changed since they were written; a size + mtime check is enough and saves hours.

If the source and destination are different filesystems (e.g. ext4 → xfs), test one disk safe end-to-end before kicking off the full sweep. Filesystem differences around xattrs and sparse representations bite at scale, not at small.

Step 4 — Final delta sync under quiesce

After the bulk copy completes, stop the SBM to catch any straggler writes:

systemctl stop cdp-server

rsync -aHAXS --delete --info=progress2 \
  /var/lib/r1soft-volumes/<old-volume-id>/ \
  /mnt/r1soft-new/r1soft-volumes/<old-volume-id>/

--delete removes anything on the destination that no longer exists on the source — needed because the merge cycle that ran between Step 3 and now might have consolidated files away. This pass should take minutes, not hours; if it doesn't, something is writing to the source you didn't account for.

Step 5 — Re-attach the safes from the new volume

Don't start the SBM yet. Edit the volume metadata so the SBM looks at the new path when it comes up:

In /usr/sbin/r1soft/conf/server.xml you'll find a Resource block per volume. The volume you added in Step 1 has a path attribute pointing at /mnt/r1soft-new/r1soft-volumes. Move the contents of <old-volume-id> into the new volume's directory and rename to the new volume's ID:

mv /mnt/r1soft-new/r1soft-volumes/<old-volume-id>/* \
   /mnt/r1soft-new/r1soft-volumes/<new-volume-id>/
chown -R cdp:cdp /mnt/r1soft-new/r1soft-volumes/<new-volume-id>/

Start the SBM:

systemctl start cdp-server
journalctl -u cdp-server -n 100 --no-pager | grep -i 'volume\|disk safe\|attached'

In the web UI go to Disk Safes → Attach Existing Disk Safe, point it at the new volume, and the SBM enumerates the safes it finds. Attach each one. The agents bound to those safes pick up the new disk safe ID automatically because the disk safe directory name (and therefore the internal ID) is preserved.

Step 6 — Re-enable schedules and remove the old volume

Once every safe verifies clean:

1. Policies → Enable schedule on each policy.
2. Recovery Point Limits → Enable cleanup.
3. Wait one full backup window. Confirm new recovery points land on the new volume by checking du -sh /mnt/r1soft-new/r1soft-volumes/<new-volume-id>/<disk-safe-id> grows.
4. In the SBM web UI: Configuration → Volumes → old volume → Delete.
5. Only then unmount the old volume.

Resist the urge to skip the wait-one-window step. If an agent's policy was misconfigured and is still writing to a phantom safe, you want to find out before the old volume is gone.

Common gotchas

• Disk safe IDs change after re-attach on SBM 6.15 and earlier. Upgrade. Old versions generate a new internal ID on attach, which orphans the agent's binding — agents then create a fresh disk safe on next run instead of resuming the existing one.
• Replication targets break. Disk safe replication tracks source-side safe IDs. After a move, re-establish the replication relationship from each migrated safe. The secondary's existing copies remain valid as restore targets but stop receiving new blocks until re-paired.
• SELinux denies access to the new path. Run restorecon -Rv /mnt/r1soft-new/r1soft-volumes after mounting, or label with chcon -R -t var_lib_t if the new path is outside /var.
• cp -a instead of rsync -S doubles your storage usage. cp on most Linux distros does not detect sparse holes by default; use cp --sparse=always if you must, but rsync is safer for large trees.
• The web UI shows the safes attached but agents reconnect to a new one. The agent's cdp.conf references the old disk safe ID. Either restart cdp-agent (it re-syncs from the SBM) or remove and re-add the server in the SBM, which pushes a new binding.

FAQ

Next steps

• Replicate the new volume offsite once it's settled: Disk Safe Replication setup.
• Tune cleanup so the new volume doesn't fill the way the old one did: R1Soft retention and recovery point cleanup.
• Buy or renew: R1Soft license.