Panellicense

R1Soft retention: clean up recovery points and free disk safe

Configure R1Soft retention so recovery points age out cleanly, the disk safe merges them on schedule, and you never wake up to a 100% full backup volume.

8 min readUpdated 2026-05-18r1soft · retention · disk-safe · recovery-points
schema: HowToschema: FAQPage

The most common R1Soft pager event is not a failed backup — it is the disk safe hitting 100 % at 04:00 because the merge job has been silently skipping for six weeks. Block-level CDP is brilliant at packing changed blocks into a single delta, but the moment retention slips out of alignment with what is actually fitting on disk, the merge queue stalls and recovery points stack up forever.

This guide walks through how R1Soft retention actually works in Server Backup Manager 6.x and 7.x, how to set it correctly for a hosting fleet, and how to dig out when the disk safe is already full. If you have not yet sized the backup volume, start with R1Soft Server Backup Manager sizing — retention only works if there is headroom to merge into.

How R1Soft retention actually works

A recovery point is a pointer to a set of blocks inside the disk safe. New points reference only the blocks that changed since the previous point — the rest are shared. Retention is enforced by a merge operation: when a policy runs and the recovery point count exceeds the configured limit, the oldest point is merged into its successor (its unique blocks are absorbed) and then deleted.

Three things follow from this design.

  • Retention is count-based, not time-based. R1Soft does not look at the calendar. It looks at how many recovery points exist for the policy and trims the tail. If your policy ran twice on Tuesday and was paused all weekend, your "last 30 days" window is in fact the last 30 successful runs.
  • Merge happens at policy run time, not on a separate schedule. The merge for recovery point N − 1 only runs when recovery point N + 1 starts. A policy that has been paused will not free any disk space until you resume it.
  • The disk safe needs free space to merge. Merging the oldest point into the next requires temporarily holding both. A disk safe at 99 % cannot merge — it will refuse the operation and the recovery point count will continue to climb until the policy itself starts failing with insufficient-space errors.

The third point is the trap. A disk safe that has gradually crept from 80 % to 99 % will appear healthy until the day merges silently stop, then will fill the remaining 1 % in a few runs.

Set retention on the policy

Retention lives on the policy, not the disk safe. Open the policy in the SBM web UI, go to Settings → Recovery Point Limits, and set:

  • Recovery point limit. The maximum count to keep before merging. This is the only hard control.
  • Archiving (optional). Tags specific points as "archived" so the merge step skips them — useful for keeping a monthly point indefinitely without growing the live retention window.

A sensible shape for a shared-hosting cPanel policy running every two hours overnight and every six hours by day:

  • Recovery point limit: 60. That gives you roughly two weeks at the configured cadence with some slack for the occasional missed run.
  • Daily archive: keep the 02:00 point flagged for 30 days.
  • Monthly archive: keep the first-of-the-month point flagged for 12 months.

The archive flag is set under Recovery Points → select point → Archive, or driven by the Archive Schedule on the policy itself. Archived points are still in the disk safe and still count against its space, so size accordingly.

Force a merge to free space

If recovery points have piled up because the policy was paused or a previous run failed mid-merge, you do not need to wait for the next scheduled run. From the SBM CLI on the server:

serverbackup-setup --merge-recovery-points \
  --disk-safe-uuid <uuid> \
  --keep <count>

Find the disk safe UUID under Disk Safes in the UI, or:

serverbackup-setup --list-disk-safes

The merge runs in the background and is visible under Reports → Task History. On a busy disk safe, merging a single recovery point with 50 GB of unique blocks takes 10–30 minutes against spinning storage and 2–5 minutes against NVMe.

Emergency: the disk safe is already full

If the SBM is at 100 % and no merge can run, work outward from cheapest to most disruptive.

  1. Free space at the volume level first. Check /var/log/r1soft/ for runaway logs (the agent log can hit 20+ GB if debug is on) and rotate them. Drop swap files or unused snapshots on the storage volume.
  2. Delete the oldest archived recovery points via the UI. Archived points are not merge-eligible, so trimming them gives you immediate room.
  3. Reduce the recovery point limit on the worst-offender policy by 25 % and run a manual merge. Once merges complete and free space climbs above 10 %, restore the limit.
  4. Move a disk safe to another volume if you have one available. The SBM supports relocating a disk safe in place — see Disk Safe replication for the move-and-promote workflow.
  5. As an absolute last resort, drop the entire disk safe for a low-priority policy and rebuild from scratch on the next run. You lose the historical recovery points for that policy but the SBM stays alive.

The fastest path back to a healthy SBM is almost always option 1 plus option 3. Manually deleting archived points (option 2) gives a one-time bump but does not address the underlying merge backlog.

Monitor disk safe utilisation before it bites

R1Soft exposes per-disk-safe utilisation through the SBM REST API and in the Reports → Disk Safe Usage view. A 90 % alert is too late — by the time you receive it, the next recovery point is already in trouble. Set the threshold at 75 % and treat it as a "investigate retention" trigger, not an emergency.

A minimal Nagios-style probe:

curl -s -u admin:$SBM_PASSWORD \
  https://sbm.example.com:8443/api/disk-safes \
  | jq -r '.[] | select(.usage_percent > 75) | "\(.name) \(.usage_percent)%"'

Pipe the result into whatever paging system you already run for Imunify360 and CloudLinux alerts. The point is to detect retention drift while there is still room to fix it without pager-driven panic.

Verifying retention is healthy

Three quick checks on a Monday morning:

# Per-policy recovery point count — should hover near the configured limit, not exceed it
serverbackup-setup --list-recovery-points --policy-id <id> | wc -l

# Disk safe free space trend — flat-ish is good, monotonic up is the failure mode
df -h /var/lib/r1soft

# Recent merge activity in the task log — if there are no merges in the last week, retention is broken
grep -i "merge" /var/log/r1soft/cdp.log | tail -50

A policy whose recovery point count sits permanently 20 % above its configured limit has a stalled merge — usually because of insufficient free space or a previous merge that crashed and left the disk safe in a state the SBM will not touch. The fix is almost always to free volume-level space and then run the CLI merge above with --keep set to the policy's configured limit.

FAQ

Why are my R1Soft recovery points not being deleted automatically?+
Either the policy has not run since the limit was exceeded (merge happens at policy run time), or the disk safe has too little free space to perform the merge. Check free space first, then resume or trigger the policy.
How do I change R1Soft retention from count-based to time-based?+
You cannot — R1Soft retention is strictly count-based. To approximate a 30-day window, set the recovery point limit to (24 ÷ hours-between-runs) × 30 and accept that paused or failed runs will skew the actual window.
What happens if I reduce the R1Soft recovery point limit?+
The next policy run will merge points down to the new limit, one merge per run. A policy going from 100 to 30 retention with hourly runs takes about 70 runs (three days) to fully trim, not a single sweep.
Can I keep some R1Soft recovery points forever without affecting retention?+
Yes — the Archive feature flags a point as merge-ineligible. Archived points still occupy disk safe space but are never trimmed by the recovery point limit, which is how you keep a monthly point for compliance without growing the live window.
Is it safe to delete R1Soft disk safe files manually to free space?+
No. The disk safe is a content-addressed block store and manual file deletion corrupts every recovery point that references the deleted blocks. Always use serverbackup-setup or the UI to delete recovery points or disk safes.
How much free space does R1Soft need to merge recovery points?+
Roughly the size of the unique blocks in the oldest point being merged, held temporarily during the merge. A practical minimum is 10 % free on the disk safe volume — below that, merges start failing intermittently.

Next steps

Related articles

All tutorials & how-tos →
how to
Set up JetBackup 5 deduplication backups to cut storage cost
JetBackup 5.4 added a deduplication backup structure that fingerprints data in chunks and stores each unique chunk once — here's how it works, where it pays off, and how to turn it on.
6 min read
how to
Plesk 360 setup guide for centralized licenses and monitoring
Plesk 360 is the SaaS control plane for everyone running more than one Plesk box — license management, uptime monitoring, and SSO into every panel from one dashboard.
7 min read
how to
Use the Plesk REST API with reseller and customer accounts
Plesk Obsidian 18.0.79 opens the REST API to reseller and customer accounts and adds file, log, and impersonation endpoints — how to authenticate and use them.
7 min read
Switch in an afternoon

Switch from your current reseller — free.

We migrate active cPanel, Plesk, LiteSpeed and CloudLinux licenses from any reseller. We prorate the first month so you never pay twice, and your customers see zero downtime during the swap.