Backups

Removed in rConfig V8.4.1

The built-in system backups feature was deprecated in 8.3.0 and removed in V8.4.1. rConfig no longer creates, schedules, lists, downloads or cleans system backups from the UI. Protect your rConfig server with the same tools you use for your other servers, as described below.

Your rConfig server holds every device configuration you have ever downloaded, plus the database that ties them to devices, policies and compliance history. Lose the server without a backup and you lose that history. This page covers what to back up, the recommended ways to do it, and how to take a one-off archive by hand.

---

What Changed in V8.4.1

The following were removed:

• The backup list, Start Backup, Clean and download actions on Settings → Data Management → Backups. The page is still there, but it now only shows a notice that points here.
• The Backup Settings page (retention and FTP destination). Old links to /settings/backup redirect to the notice.
• The Full System Backup (backup:run) and Clean Backups (backup:clean) task types in the Tasks wizard.
• The Backup Run Completed and Backup Cleanup Completed notification types, including their webhook events.

When you upgrade to V8.4.1, the upgrade migration also:

• Deletes any scheduled tasks that ran backup:run or backup:clean.
• Deletes saved backup notification preferences, defaults and webhook subscriptions, plus old backup notifications in the in-app inbox.

It does not delete archives you already have. Existing backup files stay on the server in /var/www/html/rconfig8/current/storage/app/rconfig/backups/. Copy them somewhere safe before you clean that directory up:

# List existing archives
ls -lh /var/www/html/rconfig8/current/storage/app/rconfig/backups/

# Copy them to another host
scp /var/www/html/rconfig8/current/storage/app/rconfig/backups/*.zip backupuser@backuphost:/srv/rconfig-archives/

---

What to Back Up

A complete rConfig backup has four parts. Miss one and a restore will be incomplete.

Component	Location	Why it matters
Database	MySQL/MariaDB or PostgreSQL database named in .env	Devices, tasks, policies, users, compliance history
Storage directory	/var/www/html/rconfig8/current/storage/app/rconfig/	Downloaded configurations, templates, reports
.env file	/var/www/html/rconfig8/current/.env	Database connection, mail and application settings
Application key	APP_KEY inside .env	Decrypts stored device credentials. Without it, restored credentials are unusable

Caution

Back up .env every time you change it, and keep the copy somewhere separate from the server. A database restore without the matching APP_KEY leaves every encrypted credential unreadable. See System Encryption Key for key rotation.

---

Recommended Approaches

Pick the option that matches how the rest of your infrastructure is protected.

VM Snapshots

Best for: rConfig running on VMware, Hyper-V, Proxmox or a cloud VM.

Snapshot the whole VM on a schedule from your hypervisor or cloud console. A snapshot captures the database, storage and .env in one go, and it is the fastest thing to restore. Take an extra snapshot before every rConfig upgrade.

If the database runs on a separate server, snapshot that server on the same schedule so the two stay in step.

Enterprise Backup Software

Best for: estates that already run Veeam, Commvault, Rubrik, Bacula or similar.

Add the rConfig server to your existing backup policy. Include /var/www/html/rconfig8/current/storage/app/rconfig/ and /var/www/html/rconfig8/current/.env, and use the product’s MySQL or PostgreSQL agent for the database so you get a consistent dump rather than copying live database files.

Database Dumps Plus File Copies

Best for: smaller installs, or as a second layer under one of the options above.

Schedule a cron job on the server that dumps the database and archives the storage directory and .env:

# PostgreSQL
pg_dump -U rconfig -h localhost rconfig > /srv/backups/rconfig-db-$(date +%F).sql

# MySQL / MariaDB
mysqldump -u rconfig -p rconfig > /srv/backups/rconfig-db-$(date +%F).sql

# Storage and .env
tar -czf /srv/backups/rconfig-files-$(date +%F).tar.gz \
  /var/www/html/rconfig8/current/storage/app/rconfig \
  /var/www/html/rconfig8/current/.env

Move the output off the server. A backup that lives on the same disk as rConfig does not survive a disk failure.

---

Taking a One-Off Archive by Hand

rConfig still ships the backup package the old feature was built on, so an administrator can take a single archive from the command line. This is useful before an upgrade or a risky change. It is not a replacement for a scheduled backup: nothing runs it automatically, and the archive does not appear anywhere in the UI.

# Database, storage directory and .env in one zip
php /var/www/html/rconfig8/current/artisan backup:run

# Database only
php /var/www/html/rconfig8/current/artisan backup:run --only-db

# Remove old archives according to the retention values in .env
php /var/www/html/rconfig8/current/artisan backup:clean

The archive is written to storage/app/rconfig/backups/ by default. These .env values are still read by the manual commands:

Variable	Purpose
BACKUP_DESTINATION	Disk to write to: rconfig (local, default) or ftp
BACKUP_FTP_*	FTP connection details when BACKUP_DESTINATION=ftp
BACKUP_ARCHIVE_PASSWORD	Encrypts the zip when set
KEEPALLBACKUPSFORDAYS, KEEPDAILYBACKUPSFORDAYS, KEEPWEEKLYBACKUPSFORWEEKS, KEEPMONTHLYBACKUPSFORMONTHS, KEEPYEARLYBACKUPSFORYEARS, DELETEOLDESTBACKUPSWHENUSINGMOREMEGABYTESTHAN	Retention used by backup:clean

Before running a manual backup, save a separate copy of .env:

php /var/www/html/rconfig8/current/artisan rconfig:backup-env

See CLI Commands for details.

PostgreSQL needs pg_dump

On PostgreSQL installs, backup:run calls pg_dump, which must be installed and match the server’s major version. If you see pg_dump: command not found or a version mismatch error, install the client package (postgresql-client-16 on Ubuntu/Debian, postgresql16 on RHEL) and check pg_dump --version. MySQL installs use mysqldump, which ships with the server.

---

Restoring

How you restore depends on how you backed up:

• VM snapshot: revert the VM, or restore it to a new VM, from your hypervisor or cloud console. Restart Horizon afterwards with sudo supervisorctl restart horizon:*.

• Enterprise backup software: restore the database through the product’s database agent, then restore the storage directory and .env to the same paths.

• Dumps, file copies or a manual backup:run zip: restore the database dump into an empty database, put the storage directory and .env back in place, then clear the caches:

  php /var/www/html/rconfig8/current/artisan optimize:clear
  sudo supervisorctl restart horizon:*

Caution

Restore onto the same rConfig version the backup was taken from, then upgrade. Restoring an older database under newer application code can leave migrations half-applied. If you are unsure, contact support@rconfig.com with your backup details before you start.

---

Related Documentation

• Data Purge - trim old configurations and logs so backups stay small.
• High Availability Options - replication and failover for deployments that cannot wait for a restore.