System Backups in rConfig V8 Core

After reading this page, you can run an on-demand system backup, schedule recurring backups, manage retained backup files, and understand how a restore works in rConfig V8 Core. System backups capture the whole application (settings, database, and storage) in one compressed archive, distinct from per-device configuration backups.

When to use this

Use system backups to protect a full rConfig V8 Core deployment so you can recover the application after a host failure, data corruption, or a migration to new infrastructure. For per-device config history and version comparison, use configuration backups instead. This page covers the application-level backup that bundles your settings, database, and storage together.

Tip

rConfig system backups suit smaller deployments or act as a secondary method. For larger deployments (5,000+ devices or 50GB+ storage repositories), pair them with VM-level snapshots or an enterprise backup solution for faster recovery.

Prerequisites

• A logged-in rConfig V8 Core account with access to the Backups page.
• The Horizon queue manager running, since backup jobs are queued for processing.
• Sufficient free disk space at the backup destination, typically 2-3x the size of your storage repository plus the database.
• Write access for the rConfig application to the backup destination (default: /var/www/html/rconfig/storage/app/backups).
• PostgreSQL users only: the pg_dump utility installed on the host. MySQL users do not need extra tools, as mysqldump ships with standard MySQL installs.

What gets backed up

Each system backup captures three components in a single compressed archive:

• Storage directory: all application data under /var/www/html/rconfig/storage/, including downloaded device configurations.
• Database dump: a complete export of the rConfig database (MySQL or PostgreSQL).
• .env file: the environment configuration holding application settings and database connection details.

A single archive therefore contains everything needed to restore a complete rConfig instance, with no need to coordinate separate backup sources during recovery.

How system backups work

When a backup starts, manually or from a scheduled task, rConfig:

1. Queues the backup job through the Horizon queue manager.
2. Creates the database dump using native tools (mysqldump or pg_dump).
3. Archives the rConfig application directory.
4. Includes all downloaded device configurations from the storage repository.
5. Generates a timestamped ZIP file containing every component.
6. Stores the backup locally or transfers it to the configured FTP destination.

The queue-based design keeps backup work from interfering with device polling or configuration downloads.

Backup storage capacity metrics

The Backups page shows capacity metrics at the top of the interface (also visible on the dashboard):

• Total number of backup files stored.
• Total combined size of those backups.
• Total free disk space at the destination.
• Backup destination (Local Disk or FTP server).

Monitor these regularly to avoid backup failures from insufficient storage. Backup size grows with device count, configuration file sizes and retention, database growth, and your retention policy.

Running a manual backup

To create an on-demand backup:

1. Navigate to Backups in the main navigation menu.
2. Review the capacity metrics at the top of the page.
3. Click Start Backup.
4. rConfig queues the backup job and returns control immediately.
5. Refresh the page after 1-5 minutes (depending on data volume) to see the new file in the list.

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

What affects backup processing time

Backup duration depends on:

• Queue depth: the number of pending jobs in the Horizon queue manager.
• Storage repository size: total volume of downloaded device configurations.
• Database size: device, task, and historical record counts.
• System resources: available CPU, memory, and disk I/O.

For deployments with 1,000+ devices or 100GB+ storage repositories, schedule backups during maintenance windows to avoid contention with polling.

Scheduling automated backups

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

1. From the Backups page, click Scheduled Task.
2. rConfig opens the Scheduled Tasks configuration page.
3. Create a new scheduled task with these parameters:
   • Task Type: select System Backup.
   • Schedule: set the frequency (daily, weekly, or a custom cron expression).
   • Time: choose a maintenance window with minimal activity.
   • Enabled: confirm the task is active.

Recommended backup schedules

Choose a strategy based on your environment:

Environment	Suggested schedule	Retention
Production, frequent changes	Daily, off-peak (for example 02:00 local)	7 daily, plus 4 weekly
Stable, infrequent changes	Weekly, in a maintenance window	4-6 weekly, monthly archived
Mission-critical	Twice daily, around change windows	Pair with VM snapshots, test restores regularly

Managing backup files

Downloading a backup

To download a backup for offsite storage or migration:

1. Navigate to the Backups page.
2. Locate the backup in the file list.
3. Click 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.

Deleting a backup

To remove a specific backup file:

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, while keeping enough retention for your recovery requirements.

Configuring the backup cleanup strategy

The backup cleanup strategy automates retention based on configured policies:

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

A typical retention policy keeps daily backups for 7 days, weekly backups for 4 weeks, and monthly backups for 6-12 months.

Restoring from a backup

Restores are support-assisted

Backup restoration requires assistance from rConfig support. The restore extracts application files, the database dump, and the storage repository to their correct locations, then reconciles database state with the restored application version. Contact support@rconfig.com with your backup file before attempting a restore.

The general restore process helps you plan for recovery:

1. Provide the backup ZIP file to rConfig support.
2. Support extracts the application files, database dump, and configurations.
3. Import the database dump to a clean database instance.
4. Deploy extracted application files to /var/www/html/rconfig.
5. Copy configuration files to the storage repository location.
6. Confirm application functionality, database connectivity, and configuration access.
7. Re-enable scheduled tasks and resume normal operations.

Planning restore time

Recovery time objectives (RTO) vary with backup file size, database restore time (large databases of 50GB+ take longer to import), the depth of verification checks, and support availability. For stringent RTO targets, consider VM-level snapshots for rapid infrastructure recovery and pre-staged backup files in multiple locations.

Common gotchas

Common backup gotchas

• A backup job that never completes usually means the Horizon queue manager is stopped, the destination is out of disk space, or the backup directory lacks write permissions. Check php /var/www/html/rconfig/artisan horizon:status and df -h /var/www/html/rconfig/storage/app/backups first.
• PostgreSQL backups fail with pg_dump: command not found when the PostgreSQL client tools are not installed or not on the system PATH. Install postgresql-client and confirm with which pg_dump.
• FTP transfers fail on wrong credentials, blocked firewall ports, an active/passive mode mismatch, or an exhausted FTP server. Prefer SFTP or SCP for encrypted offsite transfer.
• Backup archives contain credentials and network topology. Restrict the backup directory to the rConfig user (chmod 700) and encrypt archives before moving them offsite.

Troubleshooting

Why does my backup job never complete?

Check queue manager status and backup job progress:

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

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

Common causes: Horizon not running, insufficient disk space, a database connection timeout during the dump, or file permission issues. Resolve them by:

1. Verifying Horizon is running:

   sudo systemctl status rconfig-horizon

2. Restarting it if stopped:

   sudo systemctl restart rconfig-horizon

3. Checking disk space:

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

4. Verifying write permissions:

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

5. Reviewing Laravel logs for specific errors:

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

Why does my PostgreSQL backup fail with “pg_dump: command not found”?

The PostgreSQL client utilities are not installed or not on the PATH.

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 the installation:

   which pg_dump
   pg_dump --version

4. Retry the backup after confirming pg_dump is available.

Why is my backup file much larger than expected?

The storage repository, database, or cache may be holding more than expected.

1. Examine the 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 data that is no longer required.
4. Clear the application cache before creating backups:

   php /var/www/html/rconfig/artisan cache:clear

Why does my FTP backup transfer fail?

Check FTP configuration and network connectivity.

1. Verify FTP settings in the rConfig configuration.
2. Test FTP connectivity manually:

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

3. Check firewall rules for FTP ports (21 for control, 20 or the passive range for data).
4. Verify the FTP server has adequate free space.
5. Review Laravel logs for specific FTP error messages.
6. Switch FTP mode (active/passive) if there is a mismatch.

Best practices

Security

• Encrypt backups before transferring offsite, since archives contain credentials and topology. Use gpg --symmetric --cipher-algo AES256 rconfig_backup_YYYY-MM-DD_HH-MM-SS.zip.
• Restrict the backup directory to the rConfig user only: sudo chmod 700 /var/www/html/rconfig/storage/app/backups.
• Prefer SFTP or SCP over FTP for encrypted offsite transfer.
• Monitor access to backup files through system logs to detect unauthorized retrieval.

Performance

• Schedule backups during maintenance windows so compression and disk I/O do not impact polling or user operations.
• Implement retention policies that balance recovery needs with storage efficiency, for example 7 daily, 4 weekly, and 6 monthly backups.
• Alert when backup storage reaches 80% capacity to prevent failures from insufficient space.

Maintenance

• Review backup logs weekly to catch warnings about skipped files or partial transfers.
• Periodically download and extract a backup to validate archive integrity before you ever need it.
• Re-evaluate backup schedules, retention, and storage capacity as your device inventory grows.
• Archive monthly backups offsite for compliance or disaster recovery requirements.

Quick reference

Backup component checklist

Component	Location	Included
.env file	/var/www/html/rconfig/.env	Yes
Storage repository	/var/www/html/rconfig/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/rconfig/artisan backup:run

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

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

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

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

# Verify PostgreSQL client tools
which pg_dump
pg_dump --version

What’s next

• Schedule recurring backups with Scheduled Tasks →
• Understand the Horizon Queue Manager that processes backup jobs →
• Compare with per-device Configuration Backups →