Backups

Backups: Data Protection and Disaster Recovery for rConfig V8

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.

The backup system addresses the critical challenge of disaster recovery and data protection in network configuration management. Organizations managing thousands of device configurations need reliable mechanisms to restore operations quickly after system failures, data corruption, or infrastructure changes.

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.

Understanding rConfig Backups

What Gets Backed Up

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

• Storage Directory: All application data stored in the rConfig repository located at /var/www/html/rconfig8/current/storage/
• 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 the Horizon queue manager for processing
2. Creates the database dump: Generates a complete database export using native tools (mysqldump or pg_dump)
3. Archives application files: Compresses the rConfig application directory
4. Includes configuration repository: Adds all downloaded device configurations to the archive
5. Generates compressed package: Creates a timestamped ZIP file containing all components
6. Stores or transfers backup: Saves the backup locally or transfers to configured FTP destination

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 backup page displays critical capacity metrics at the top of the interface (also visible on the dashboard):

• Total number of backup files: How many backup archives are currently stored
• Total size of backup files combined: Cumulative storage consumption
• Total free disk space: Remaining capacity on the backup destination
• Backup destination: Storage location (Local Disk or FTP server)

Organizations should monitor these metrics regularly to prevent backup failures due to insufficient storage capacity. Consider that backup size grows proportionally with:

• The number of managed devices
• Configuration file sizes and retention periods
• Database growth over time
• Backup retention policies

Prerequisites

Before implementing rConfig backups, ensure:

• 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-3x the size of your configuration repository plus database)
• Queue manager operational: The Horizon queue manager must be running to process backup jobs
• Write permissions: The rConfig application must have write access to the backup destination directory (default: /var/www/html/rconfig8/current/storage/app/backups)

Running Manual Backups

Creating a Backup On-Demand

To execute an immediate backup:

1. Navigate to Backups from the main navigation menu
2. Review the capacity metrics displayed 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-5 minutes (depending on data volume) to see the new backup file in the list

The backup filename follows the pattern: rconfig_backup_YYYY-MM-DD_HH-MM-SS.zip

Understanding Backup Processing Time

Backup duration varies based on several factors:

• Queue depth: Number of pending jobs in the Horizon queue manager
• 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 Scheduled Task button
2. This navigates to the Scheduled Tasks configuration page
3. Create a new scheduled task with the following parameters:
   • Task Type: Select “System Backup”
   • Schedule: Define frequency (daily, weekly, or custom cron expression)
   • Time: Choose a maintenance window with minimal system activity
   • Enabled: Ensure the task is activated

Recommended Backup Schedules

Consider these scheduling strategies based on your environment:

Production environments with frequent changes:

• Daily backups during off-peak hours (e.g., 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-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.

Invoking Backup Cleanup Strategy

The Backup Cleanup Strategy automates retention management based on configured policies:

1. Navigate to the System Settings > Backups Settings page
2. Change the Backup Strategy Settings as required

Configure cleanup strategies to balance recovery needs with storage capacity. Typical retention policies:

• Keep daily backups for 7 days
• Keep weekly backups for 4 weeks
• Keep monthly backups for 6-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 [email protected] 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
• Pre-staged backup files in multiple locations

Troubleshooting

Symptom: Backup Job Never Completes

Diagnosis: Check queue manager 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 queue manager not running
• Insufficient disk space on backup destination
• Database connection timeout during dump operation
• File permission issues preventing archive creation

Resolution Steps:

1. Verify Horizon is running:

   sudo systemctl status rconfig-horizon

2. If stopped, restart the service:

   sudo systemctl restart rconfig-horizon

3. Check disk space:

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

4. Verify write permissions:

   ls -la /var/www/html/rconfig8/current/storage/app/backups
   sudo chown -R www-data:www-data /var/www/html/rconfig8/current/storage/app/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 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 yum install postgresql16

3. Verify installation:

   which pg_dump
   pg_dump --version

4. Retry 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 rconfig_backup_YYYY-MM-DD_HH-MM-SS.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 application cache before creating backups:

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

Symptom: FTP Backup Transfer Fails

Diagnosis: Check FTP configuration and network connectivity.

Possible Causes:

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

Resolution Steps:

1. Verify FTP settings in rConfig configuration

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 passive range for data)

4. Verify FTP server has adequate free space

5. Review Laravel logs for specific FTP error messages

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

Best Practices

Security

Protect backup files with encryption: Backup archives contain sensitive configuration data including credentials and network topology. Consider encrypting backups before transferring to offsite storage or FTP servers. Use tools like gpg for encryption:

gpg --symmetric --cipher-algo AES256 rconfig_backup_YYYY-MM-DD_HH-MM-SS.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/backups

Use secure transfer protocols: If transferring backups offsite, prefer SFTP or SCP over FTP for encrypted data transfer. Configure rConfig to use SFTP when offsite backup storage is required.

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. Implement automated cleanup strategies that balance recovery needs with storage efficiency. A typical policy: retain 7 daily, 4 weekly, and 6 monthly backups.

Monitor backup storage capacity: Configure alerting when backup storage reaches 80% capacity to prevent backup failures due to insufficient space. The backup page dashboard metrics provide this visibility.

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 through differential or incremental approaches.

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 to ensure they remain adequate.

Archive long-term backups offsite: For compliance or disaster recovery requirements, archive monthly backups to offsite storage facilities or cloud storage services. This protects against site-wide failures affecting both production and backup systems.

Related Documentation

• Scheduled Tasks - Configure automated backup schedules
• Horizon Queue Manager - Understanding the queue system that processes backups
• Database Configuration - Database setup and optimization affecting backup performance
• System Requirements - Capacity planning for backup storage

Quick Reference

Backup Component Checklist

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

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/backups

# List backup files with sizes
ls -lh /var/www/html/rconfig8/current/storage/app/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

While rConfig provides robust backup capabilities, remember that backups are only valuable when tested and validated. Regular restore testing and capacity monitoring ensure your backup strategy protects your critical network configuration data when needed most.