Backups: Data Protection and Disaster Recovery for rConfig V8

Deprecated (from 8.3.0)

rConfig’s built-in backup feature is deprecated and will be removed in a future release. See Enterprise Backup Alternatives below for the recommended replacement approach.

System backups provide comprehensive protection for your rConfig V8 deployment by creating complete snapshots of your configuration data, application files, and database. While rConfig V8 offers built-in backup capabilities, organizations can leverage their existing infrastructure, such as VM snapshots, enterprise backup solutions, or filesystem-level backups, as alternatives or complementary protection strategies.

When to Use This Page

Use this page to run a one-off backup, set up a recurring backup schedule, plan storage capacity, or troubleshoot a backup job that failed. If you need to actually restore from a backup, see Restoring from Backup below, which requires rConfig support.

Enterprise Backup Alternatives

Tip

rConfig backup functionality is recommended for smaller deployments or as a secondary backup method. For larger deployments (5,000+ devices or 50GB+ configuration repositories), we strongly suggest using enterprise backup solutions or VM-level snapshots for more efficient recovery.

Prerequisites

• PostgreSQL users only: the pg_dump utility must be installed on the operating system. MySQL users do not require additional utilities, as mysqldump is included with standard MySQL installations.
• Sufficient disk space: the backup destination must have adequate free space to store compressed archives (typically 2 to 3 times the size of your configuration repository plus database).
• Queue manager operational: Horizon must be running to process backup jobs (see Horizon Queue Manager).
• Write permissions: the rConfig application must have write access to the backup destination directory (default: /var/www/html/rconfig8/current/storage/app/rconfig/backups).

Understanding rConfig Backups

What Gets Backed Up

rConfig system backups capture three essential components in a single compressed archive:

• Storage directory: all application data under /var/www/html/rconfig8/current/storage/, including the configuration repository.
• Database dump: a complete export of the rConfig database (MySQL or PostgreSQL format).
• .env file: the environment configuration file containing application settings and database connection details.

This comprehensive approach ensures that a single backup file contains everything needed to restore a complete rConfig instance, eliminating the complexity of coordinating multiple backup sources during recovery operations.

How System Backups Work

When a backup is initiated (manually or via scheduled task), the system:

1. Queues the backup job: the request is sent to Horizon for processing.
2. Creates the database dump: generates a complete database export using native tools (mysqldump or pg_dump).
3. Archives the storage directory: compresses storage/, which includes the configuration repository, and the .env file into the same package.
4. Generates a compressed package: creates a ZIP archive named rConfigBackup_<timestamp>.zip, for example rConfigBackup_2026-07-08-14-30-00.zip.
5. Stores the backup: saves the archive to the configured destination, either the local rconfig disk or an FTP server.

The queue-based architecture ensures backup operations don’t interfere with critical rConfig functions like device polling or configuration downloads.

Backup Storage Capacity Planning

The Backups page (System Settings → Data Management → Backups) shows a Backup Status card at the top with:

• Backup Destination badge: Local disk (rconfig) or FTP.
• Last Backup: when the most recent backup completed.
• Disk Percent Used and Disk Free Space: capacity on the backup destination.
• Total Backup Size and Total Files: cumulative storage consumed by stored backups.
• A Clean button to run the cleanup strategy immediately.

Organizations should monitor these metrics regularly to prevent backup failures due to insufficient storage capacity. Backup size grows proportionally with the number of managed devices, configuration file sizes and retention periods, database growth over time, and backup retention policies.

Running Manual Backups

Creating a Backup On-Demand

To execute an immediate backup:

1. Navigate to Backups (System Settings → Data Management → Backups).
2. Review the Backup Status card at the top of the page.
3. Click the Start Backup button.
4. The system queues the backup job and returns control immediately.
5. Refresh the page after 1 to 5 minutes (depending on data volume) to see the new backup file in the list.

The backup filename follows the pattern rConfigBackup_<Y-m-d-H-i-s>.zip, for example rConfigBackup_2026-07-08-14-30-00.zip.

Understanding Backup Processing Time

Backup duration varies based on several factors:

• Queue depth: number of pending jobs Horizon is processing.
• Configuration repository size: total volume of downloaded device configurations.
• Database size: number of devices, policies, and historical compliance records.
• System resources: available CPU, memory, and disk I/O capacity.

For deployments with 1,000+ devices or 100GB+ configuration repositories, consider scheduling backups during maintenance windows to avoid resource contention with polling operations.

Configuring Scheduled Backups

Setting Up Automated Backup Tasks

Regular automated backups are essential for production environments. To configure scheduled backups:

1. From the Backups page, click the Schedule Backup button. This takes you to Tasks, the same place covered in Scheduled Tasks.
2. Create a new task and select the Other Tasks → Full System Backup command (backup:run). This task type only needs a schedule, it has no other options to configure.
3. Set the cron schedule, choosing a maintenance window with minimal system activity.
4. Save and ensure the task is enabled.

A separate task type cleans up old backups

Other Tasks → Clean Backups (backup:clean) is a second, independent task type in the same wizard. Schedule it alongside Full System Backup if you want cleanup to run on its own cadence rather than relying solely on the retention policy described below.

Recommended Backup Schedules

Consider these scheduling strategies based on your environment:

Production environments with frequent changes:

• Daily backups during off-peak hours (for example, 2:00 AM local time).
• Retain 7 daily backups for recent recovery needs.
• Weekly backups retained for 4 weeks for longer-term recovery.

Stable environments with infrequent changes:

• Weekly backups during maintenance windows.
• Retain 4 to 6 weekly backups.
• Monthly backups archived to long-term storage.

High-availability or mission-critical deployments:

• Twice-daily backups (before and after peak configuration change windows).
• Coordinate rConfig backups with VM-level snapshots for layered protection.
• Test restore procedures quarterly.

Managing Backup Files

Downloading Backups

To download a backup file for offsite storage or migration:

1. Navigate to the Backups page.
2. Locate the desired backup in the file list.
3. Click on the backup filename.
4. The ZIP archive downloads to your local system.

Store downloaded backups in a secure location separate from your rConfig server to protect against site-wide failures or storage system corruption.

Deleting Individual Backups

To remove specific backup files:

1. Navigate to the Backups page.
2. Locate the backup file to delete.
3. Click the delete icon next to the filename.
4. Confirm the deletion when prompted.

Delete obsolete backups to reclaim disk space, but ensure you maintain adequate retention for your recovery requirements.

Setting the Backup Retention (Cleanup) Strategy

The retention policy controls which backups are kept automatically. To configure it:

1. Navigate to System Settings → System Management → Backup Settings.
2. Set the retention values: how many days to keep all backups, how many daily/weekly/monthly/yearly backups to retain, and the maximum megabytes to use before the oldest backups are deleted.
3. Save. These values are read the next time a cleanup runs, whether triggered by the Clean button on the Backups page, a scheduled Clean Backups task, or an automatic cleanup pass.

Typical retention policies:

• Keep daily backups for 7 days.
• Keep weekly backups for 4 weeks.
• Keep monthly backups for 6 to 12 months.

Restoring from Backup

Caution

Backup restoration requires assistance from rConfig support. The restore process involves extracting application files, database dumps, and configuration repositories to their correct locations, then reconciling database states with the restored application version. Contact support@rconfig.com with your backup file before attempting restoration.

Restore Process Overview

While the detailed restore procedure requires support coordination, understanding the general process helps organizations plan for recovery scenarios:

1. Transfer backup file: provide the backup ZIP file to rConfig support.
2. Extract archive components: support extracts application files, database dump, and configurations.
3. Restore database: import the database dump to a clean database instance.
4. Restore application files: deploy extracted application files to /var/www/html/rconfig8/current.
5. Restore configurations: copy configuration files to the repository location.
6. Verify integrity: confirm application functionality, database connectivity, and configuration accessibility.
7. Resume operations: re-enable scheduled tasks and resume normal operations.

Restoration Time Planning

Recovery time objectives (RTO) vary based on:

• Backup file size: larger archives take longer to transfer and extract.
• Database restoration: large databases (50GB+) require extended import time.
• Verification procedures: thorough integrity checks add time but ensure reliability.
• Support availability: coordinate with support schedules for planned maintenance.

Organizations with stringent RTO requirements should consider VM-level snapshots for rapid infrastructure recovery, database replication for high-availability scenarios, and pre-staged backup files in multiple locations.

Troubleshooting

Symptom: Backup Job Never Completes

Diagnosis: check Horizon status and backup job progress:

# Check Horizon queue status
php /var/www/html/rconfig8/current/artisan horizon:status

# Check for failed jobs
php /var/www/html/rconfig8/current/artisan queue:failed

Possible causes:

• Horizon is not running.
• Insufficient disk space on the backup destination.
• Database connection timeout during the dump operation.
• File permission issues preventing archive creation.

Resolution steps:

1. Check whether Horizon is running under Supervisor:

   sudo supervisorctl status horizon

2. If it isn’t running, restart it:

   sudo supervisorctl restart horizon:*

   See Horizon Queue Manager for the full Supervisor setup.

3. Check disk space:

   df -h /var/www/html/rconfig8/current/storage/app/rconfig/backups

4. Verify write permissions:

   ls -la /var/www/html/rconfig8/current/storage/app/rconfig/backups
   sudo chown -R www-data:www-data /var/www/html/rconfig8/current/storage/app/rconfig/backups

5. Review Laravel logs for specific errors:

   tail -f /var/www/html/rconfig8/current/storage/logs/laravel.log

Symptom: PostgreSQL Backup Fails with “pg_dump: command not found”

Diagnosis: PostgreSQL client utilities are not installed.

Possible causes:

• PostgreSQL server installed without client tools.
• pg_dump binary not in the system PATH.
• Incorrect PostgreSQL version installed.

Resolution steps:

1. Install PostgreSQL client utilities (Ubuntu/Debian):

   sudo apt-get update
   sudo apt-get install postgresql-client-16

2. Install PostgreSQL client utilities (RHEL/CentOS):

   sudo dnf install postgresql16

3. Verify installation:

   which pg_dump
   pg_dump --version

4. Retry the backup operation after confirming pg_dump is available.

Symptom: Backup File Size Much Larger Than Expected

Diagnosis: review backup contents to identify large components.

Possible causes:

• Configuration repository contains historical versions accumulating over time.
• Database includes large audit logs or compliance history tables.
• Application files include unnecessary temporary or cache files.

Resolution steps:

1. Extract and examine backup contents:

   unzip -l rConfigBackup_2026-07-08-14-30-00.zip | sort -k4 -n -r | head -20

2. Review configuration retention policies and purge obsolete versions.

3. Archive or truncate historical compliance data if not required.

4. Clear the application cache before creating backups:

   php /var/www/html/rconfig8/current/artisan cache:clear

Symptom: FTP Backup Transfer Fails

Diagnosis: check the FTP configuration and network connectivity.

Possible causes:

• Incorrect FTP credentials in rConfig settings.
• Network firewall blocking the FTP connection.
• FTP server disk space exhausted.
• Passive vs. active FTP mode mismatch.

Resolution steps:

1. Verify the FTP settings in System Settings → System Management → Backup Settings.

2. Test FTP connectivity manually:

   ftp ftp.yourserver.com
   # Enter credentials and attempt file transfer

3. Check firewall rules for FTP ports (21 for control, 20 or a passive range for data).

4. Verify the FTP server has adequate free space.

5. Review Laravel logs for specific FTP error messages.

6. Consider switching FTP mode (active/passive) in the FTP server configuration.

Common Gotchas

Common gotchas

• The backup destination directory is storage/app/rconfig/backups, not storage/app/backups. Scripts or cron jobs that reference the wrong path will silently miss the archives.
• Horizon in rConfig is managed by Supervisor, not systemctl. Use supervisorctl, not systemctl, to check or restart it.
• Deleting a backup through the UI removes both the file and its database record even if the file is already missing from disk, so a “successful” delete doesn’t always mean a file existed to remove.
• The retention policy on Backup Settings only runs when a cleanup is triggered, either the Clean button, a scheduled Clean Backups task, or an automatic pass. Saving new retention values does not retroactively delete anything by itself.

Best Practices

Security

Protect backup files with encryption: backup archives contain sensitive configuration data including credentials and network topology. rConfig can encrypt the archive itself if a BACKUP_ARCHIVE_PASSWORD is configured; otherwise, encrypt manually before transferring to offsite storage or an FTP server, for example with gpg:

gpg --symmetric --cipher-algo AES256 rConfigBackup_2026-07-08-14-30-00.zip

Restrict access to backup storage: limit file system permissions on the backup directory to the rConfig application user only:

sudo chmod 700 /var/www/html/rconfig8/current/storage/app/rconfig/backups

Use secure transfer protocols: if transferring backups offsite, prefer SFTP or SCP over FTP for encrypted data transfer.

Audit backup file access: monitor access to backup files through system logs to detect unauthorized retrieval attempts.

Performance

Schedule backups during maintenance windows: backup operations consume system resources (CPU for compression, disk I/O for reading configurations and database). Schedule automated backups during periods of low system activity to avoid impacting device polling or user operations.

Implement backup rotation policies: excessive backup retention exhausts disk space and complicates backup management. A typical policy is to retain 7 daily, 4 weekly, and 6 monthly backups.

Monitor backup storage capacity: keep an eye on the Backup Status card’s Disk Percent Used to avoid backup failures caused by insufficient space.

Consider differential or incremental strategies for large deployments: organizations managing 5,000+ devices or 500GB+ configuration repositories should contact rConfig support about enterprise backup strategies that reduce backup size and duration.

Maintenance

Review backup logs regularly: even successful backups may include warnings about skipped files or partial transfers. Review logs weekly to identify potential issues before they impact recovery operations.

Validate backup file integrity: periodically download and extract backup files to verify archive integrity. Corrupted backup files discovered during disaster recovery are too late to address.

Update backup strategies as environment grows: backup duration and storage requirements increase as your device inventory and configuration repository grow. Re-evaluate backup schedules, retention policies, and storage capacity quarterly.

Archive long-term backups offsite: for compliance or disaster recovery requirements, archive monthly backups to offsite storage facilities or cloud storage services.

Quick Reference

Backup Component Checklist

Component	Location	Included in Backup
.env file	/var/www/html/rconfig8/current/.env	Yes
Configuration repository	/var/www/html/rconfig8/current/storage	Yes
Database dump	MySQL or PostgreSQL database	Yes

Common Backup Commands

# Manually trigger a backup (runs the backup job immediately)
php /var/www/html/rconfig8/current/artisan backup:run

# Check Horizon status (backup job processor)
php /var/www/html/rconfig8/current/artisan horizon:status

# View failed backup jobs
php /var/www/html/rconfig8/current/artisan queue:failed

# Check backup directory disk space
df -h /var/www/html/rconfig8/current/storage/app/rconfig/backups

# List backup files with sizes
ls -lh /var/www/html/rconfig8/current/storage/app/rconfig/backups

# Verify PostgreSQL client tools
which pg_dump
pg_dump --version

Summary

rConfig V8’s backup system provides comprehensive protection for your network configuration management deployment through automated, scheduled backups that capture application files, configuration repositories, and database contents in single compressed archives. Organizations can leverage this built-in capability alongside existing infrastructure backup solutions to create layered protection strategies.

Key takeaways for effective backup management:

• Automate backup schedules during maintenance windows to ensure consistent protection without manual intervention.
• Monitor storage capacity proactively to prevent backup failures due to insufficient disk space.
• Test restore procedures regularly to validate backup integrity and familiarize staff with recovery workflows.
• Coordinate with support for restoration operations to ensure proper database reconciliation and application integrity.
• Implement retention policies that balance recovery requirements with storage efficiency.

Related Documentation

• Scheduled Tasks - configure automated backup and cleanup schedules.
• Horizon Queue Manager - the queue system that processes backup jobs.
• rConfig V8 Pro Installation Guide - database setup and system requirements affecting backup performance.