Restoring a backup from R1Soft Server Backup Manager (formerly CDP) is straightforward once you know which recovery point to select and which restore method matches your incident. Whether you need to recover a single overwritten configuration file, restore a corrupted MySQL database table, or bring an entire damaged filesystem back online, selecting the wrong options can accidentally overwrite current production data.
Production Note: Before restoring anything on a live server, verify the exact timestamp of the recovery point and understand whether the restore task will overwrite existing files or stage them into an alternate directory.
At a Glance
- Log in to the R1Soft Backup Manager web interface.
- Select Protected Machines and navigate to the target server’s Recovery Points.
- Choose the required restore mode: Browse Files, Browse Databases, or Bare-Metal Restore.
- Select the specific files, tables, or mount points to recover.
- Configure the destination path and file overwrite policy.
- Launch the restore task and monitor progress in the Task History.
- Verify file ownership, permissions, and service stability on the target host.
Prerequisites
Before initiating a restore, ensure the following conditions are met:
- Administrative or operator access to the R1Soft Server Backup Manager web interface.
- Target server’s Backup Agent service (
cdp-agent/sbm-agent) is running and accessible on TCP port 1167. - A healthy, completed recovery point with no active Disk Safe locks.
- Sufficient available disk space on the target server partition to receive the restored data.
- Root access to the target server to verify restored file ownership and restart dependent services.
Step 1: Access R1Soft Backup Manager and Locate the Target Machine
Log in to your R1Soft Server Backup Manager dashboard using your administrative credentials.
From the left-hand navigation menu, click on Protected Machines (or Servers in earlier R1Soft 5.x releases).
Locate the target server in the list. Check the status indicator next to the machine name. A green icon indicates that the Backup Manager has active network connectivity to the target server’s backup agent on port 1167.
Step 2: Browse Available Recovery Points
On the right-hand side of the target machine row, click the Actions gear icon and select Open Recovery Points (or click the recovery point counter icon directly).
The Recovery Points window displays a chronological table of all captured point-in-time snapshots stored in the Disk Safe.
Key details to verify before proceeding:
- Created Time: The exact timestamp when the backup snapshot was taken.
- Status: Must show a green checkmark indicating a clean, uncorrupted snapshot.
- Type: Indicates whether the snapshot was a scheduled replication or a manual on-demand run.
Identify the latest known good recovery point prior to the data corruption or file deletion event.
Step 3: Choose the Restore Method
R1Soft provides three distinct restore workflows depending on the type of data you need to recover.
Method A: Restoring Individual Files and Directories
Click the Browse (folder) icon in the Actions column next to your selected recovery point.
The file browser window loads the virtual snapshot of the filesystem:
- Expand the directory tree to navigate to the affected directory (for example,
/var/www/html/or/etc/nginx/). - Check the boxes next to the specific files or folders you need to restore.
- Click the Restore Selected button in the top toolbar.
Method B: Restoring MySQL / MariaDB Databases
If database add-ons are enabled in your R1Soft policy:
- Click the Browse Databases icon in the Actions column of the recovery point.
- Expand the database instance to view all individual databases and tables.
- Select the required database (e.g.,
app_production) or specific tables. - Click Restore Selected Databases.
Method C: Restoring Entire Mount Points or Disks
For full filesystem recovery:
- Select the recovery point and click Restore Files or Bare-Metal Restore.
- Select the entire volume root (
/) or specific storage volume. - Ensure you have out-of-band console access (KVM/IPMI) if performing major operating system rollbacks.
Step 4: Configure Destination and Overwrite Rules
When you click Restore Selected, the Restore Files Wizard dialog opens. Configure the following critical settings:
- Restore to Original Location vs. Alternate Location:
- Original Location: Overwrites or merges data directly into the live filesystem paths.
- Alternate Location: Restores files into a staging directory (e.g.,
/tmp/r1soft_restore/). Staging is strongly recommended for production environments so you can manually inspect and diff files before moving them into place.
- Overwrite Existing Files:
- Check Overwrite Existing Files only if you are confident that newer changes should be replaced.
- Leave unchecked if you want R1Soft to skip files that already exist on the target filesystem.
- Preserve Permissions & Ownership:
- Ensure Restore File Permissions and Restore File Ownership are checked to prevent files from reverting to
root:root.
- Ensure Restore File Permissions and Restore File Ownership are checked to prevent files from reverting to
Step 5: Execute the Restore Task and Monitor Progress
Click Restore to initiate the data transfer.
The Backup Manager immediately creates a restore job and redirects you to the Task History monitor.
You can inspect the live progress log:
Task Type: Restore Files
State: Running
Bytes Transferred: 412 MB / 1.2 GB
Files Restored: 1,420 / 3,890
Throughput: 45.2 MB/sOnce completed, the task state transitions to Finished with a green status badge.
Step 6: Verify Restored Data and Service State on Target Server
Log in to the target server via SSH as root to inspect the restored data and verify file permissions:
# Check the timestamp and permissions of the restored files
ls -la /var/www/html/config.php
# If restored to a staging directory, verify contents before moving
ls -la /tmp/r1soft_restore/If restoring database tables, verify the database service and test database consistency:
# Check database daemon status
systemctl status mariadb
# or for MySQL:
systemctl status mysqld
# Check table status using mysqlcheck
mysqlcheck -u root -p app_productionAfter confirming the files or databases are valid, restart any dependent application daemons (e.g., php-fpm, nginx, httpd) if configuration files were updated.
Troubleshooting
Problem: “Cannot connect to backup agent on port 1167”
Possible cause: The R1Soft Backup Agent daemon (cdp-agent) is stopped on the target server, or a host-level firewall (UFW, Firewalld, CSF) is blocking incoming connections from the Backup Manager IP.
Check:
# On Ubuntu/Debian:
systemctl status cdp-agent
# On AlmaLinux/RHEL:
systemctl status sbm-agent
# or:
/etc/init.d/cdp-agent statusSolution: Start the agent daemon and verify that port 1167 is open for the Backup Manager IP address:
systemctl restart cdp-agent
# For firewalld:
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="BACKUP_MANAGER_IP" port port="1167" protocol="tcp" accept'
firewall-cmd --reloadProblem: “Restore failed: No space left on device”
Possible cause: The destination partition on the target machine does not have sufficient free disk space or available inodes to unpack the restored archive.
Check:
# Check disk space and inode utilization
df -h
df -iSolution: Free up temporary space or select an alternate destination mount point with sufficient capacity in the restore wizard.
Problem: “Restored files have root:root ownership and 600 permissions”
Possible cause: The “Restore File Ownership and Permissions” option was unchecked, or user UID/GID mappings changed on the target server since the backup snapshot was taken.
Check:
ls -ld /var/www/html/Solution: Correct the ownership manually using chown and chmod for your web server user:
# Example for web content owned by www-data or nginx:
chown -R www-data:www-data /var/www/html/
# or on RHEL/AlmaLinux:
chown -R nginx:nginx /var/www/html/Problem: “Disk Safe is in a Read-Only State”
Possible cause: The Disk Safe volume on the Backup Manager experienced an ungraceful shutdown, filesystem error, or reached its storage quota.
Check: Inspect the Disk Safe health in Disk Safes >> Actions >> Verify Disk Safe.
Solution: Run a Disk Safe verification task from the R1Soft web console. Once the verification finishes repairing the internal SQLite metadata journal, the Disk Safe will return to an active read-write state.
Verify the Configuration
To confirm that the recovery was successful and no subtle corruption exists:
- Verify File Checksums: Compare checksums against known reference hashes if restoring application binaries:
sha256sum /var/www/html/index.php - Verify Application Response: Test the live website or API endpoint to ensure no HTTP 500 errors or missing dependency warnings occur:
curl -I https://example.com/ - Verify Scheduled Backup Resumption: Ensure that the next scheduled R1Soft backup policy runs normally and creates a new incremental delta point without errors.
Production Checklist
- Verified the exact timestamp of the recovery point before starting.
- Checked available disk space on the target server (
df -h). - Confirmed whether original or alternate staging destination is appropriate.
- Confirmed overwrite settings to prevent unintentional data loss.
- Monitored the task in the Backup Manager Task History until completion.
- Verified user ownership (
chown) and file permissions (chmod). - Verified database table consistency with
mysqlcheckif databases were restored. - Tested end-user application workflows to confirm normal operations.
Frequently Asked Questions
Can I restore only a single file from a large multi-terabyte R1Soft backup?
Yes. R1Soft uses block-level indexing, allowing you to browse the virtual directory structure of any recovery point and restore individual files or folders without downloading or extracting the entire disk image.
Does an R1Soft restore overwrite files that were modified after the backup?
Only if you select the Overwrite Existing Files checkbox in the Restore Wizard. If unchecked, R1Soft will skip existing files and only restore files that are currently missing from the target directory.
Can I restore files to a completely different server?
Yes. In the Restore Wizard, choose Alternate Location and select any other registered Protected Machine that has an active R1Soft agent installed.
How does R1Soft handle database restores while MySQL is running?
For granular table restores, R1Soft streams the table data directly through the MySQL client connection. For full database directory restores, it is recommended to stop the database service, perform the filesystem restore, and restart the daemon to prevent InnoDB engine locks.
Related Guides & Services
- How to Install SSL on R1Soft Backup Manager Using Certbot
- How to Migrate Disk Safe from One R1Soft Backup Manager to Another
- JetBackup 5 Restore Verification and Troubleshooting
- Server Backup Management Services
- Emergency Server Support & Incident Response
Need Help with Production Server Backups?
If you manage mission-critical servers and need assistance configuring enterprise backup schedules, disaster recovery testing, or database integrity verification, our senior systems engineering team can help.