Backing Up GUI Configuration: Difference between revisions

Latest revision as of 16:48, 8 January 2026

This guide covers backing up and restoring VoIPmonitor GUI configuration data (users, sensors, alerts, dashboards). It does not cover CDR/PCAP data backup.

Quick Reference

Task	Method	Command/Path
One-time backup	GUI	Tools → Backup & restore → select "configuration tables" + "configuration files"
Automated backup	CLI	`php run.php backupGuiTables -t config -f backup.sql`
Restore	GUI	Tools → Backup & restore → "restore"
Restore	CLI	`php run.php restoreGuiTables -t config -f backup.sql`

What Gets Backed Up:

Configuration Tables: Users, sensors, capture rules, alerts, dashboards, reports
Configuration Files: PHP config files (configuration.php)

⚠️ Warning: Restoring overwrites existing settings. Perform on fresh GUI or accept data loss.

GUI Backup (Quick Method)

Ideal for one-time backups before upgrades or migrations.

Navigate to GUI → Tools → Backup & restore
Select "backup GUI: configuration tables"
Select "backup GUI: configuration files"
Click backup and download the generated file

To Restore:

Navigate to GUI → Tools → Backup & restore
Select "restore"
Upload the backup file

Automated CLI Backup

For production environments requiring scheduled backups.

Backup Script

Create /usr/local/sbin/backup_voipmonitor_gui.sh:

#!/bin/bash
# VoIPmonitor GUI Configuration Backup Script

BACKUP_DIR="/var/backups/voipmonitor_gui"
RETENTION_DAYS=30
RUN_SCRIPT="/var/www/html/php/run.php"
DAY=$(date "+%Y-%m-%d")

mkdir -p "$BACKUP_DIR"

# Export configuration and data tables
php "$RUN_SCRIPT" backupGuiTables -t config -f "$BACKUP_DIR/config_tables-${DAY}.sql"
php "$RUN_SCRIPT" backupGuiTables -t data -f "$BACKUP_DIR/data_tables-${DAY}.sql"
php "$RUN_SCRIPT" backupGuiConfigurationFiles -f "$BACKUP_DIR/config_files-${DAY}.tar.gz"

# Cleanup old backups
find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" \( -name '*.sql' -o -name '*.tar.gz' \) -delete

echo "Backup complete: $BACKUP_DIR"

Setup

# Make executable and test
chmod +x /usr/local/sbin/backup_voipmonitor_gui.sh
/usr/local/sbin/backup_voipmonitor_gui.sh

# Schedule daily at 3:30 AM
crontab -e
# Add: 30 3 * * * /usr/local/sbin/backup_voipmonitor_gui.sh > /var/log/voipmonitor_backup.log 2>&1

CLI Restore

cd /var/www/html
php php/run.php restoreGuiTables -t config -f /var/backups/voipmonitor_gui/config_tables-YYYY-MM-DD.sql
php php/run.php restoreGuiTables -t data -f /var/backups/voipmonitor_gui/data_tables-YYYY-MM-DD.sql

# Restore config files
tar xzf /var/backups/voipmonitor_gui/config_files-YYYY-MM-DD.tar.gz -C /var/www/html/

What IS and IS NOT Transferred

Transferred	NOT Transferred
User accounts, permissions, groups	Alert-to-sensor assignments (reconfigure manually)
Sensor definitions	Report-to-sensor assignments (reconfigure manually)
Alert/report definitions	Sensor user access permissions (reassign manually)
Dashboards, capture rules, filters	CDR data, PCAP files

ℹ️ Note: Restore replaces data, it does NOT merge. Users/sensors with same ID are overwritten.

Dashboard-Only Migration

To transfer only dashboards between GUI instances without other settings.

Simple Method (GUI)

Use standard Backup & restore - this transfers dashboards along with other config. Users are included.

Advanced Method (SQL Extraction)

Dashboards are stored in the custom_config table.

# On source server: create backup
cd /var/www/html
php php/run.php backupGuiTables -t config -f /tmp/old_config.sql

# Extract only custom_config INSERT statements
grep "^INSERT INTO \`custom_config\`" /tmp/old_config.sql > /tmp/dashboards_only.sql

# On target server: import
mysql -u voipmonitor_user -p voipmonitor < /tmp/dashboards_only.sql

ℹ️ Note: Folder structures are NOT preserved. Recreate folders manually after import.

Server Migration

Fresh Installation Method (Recommended)

Best for EOL systems or when historical data is not needed.

Backup on old server:
- GUI config: Tools → Backup & restore → "configuration tables"
- Sniffer config: cp /etc/voipmonitor.conf /tmp/
- GUI PHP config: cp /var/www/html/*/configuration.php /tmp/
Fresh install on new server (see Sniffer_installation, GUI_installation)
Restore configuration:
- GUI: Tools → Backup & restore → "restore"
- Sniffer: cp voipmonitor.conf.backup /etc/voipmonitor.conf
- Update interface, spooldir, server_bind for new environment
Update remote probes (if distributed): Change server_destination to new server IP
Test with subset of traffic before full cutover

💡 Tip: To preserve trial license on new system, use CLI restore with --exclude-table system

Data Migration Method

For transferring historical CDR data with minimal downtime. See Redundant_database for:

Dump/Restore: Simple mysqldump with downtime
Online Migration: Use voipmonitor-migrate.conf for zero-downtime sync

Cross-OS / Cloud Migration

⚠️ Warning: Do NOT clone binaries between different OS versions. Always perform fresh installation.

Download GUI package matching destination PHP version (see Re-install_the_GUI)
For database version mismatches, use migration instance instead of direct mysqldump

Cloud Token Migration

Each cloud token has its own database. To migrate alerts/reports between tokens:

Contact VoIPmonitor support - request temporary trial cloud license
Support restores old database to temporary license
Export config from temporary license via Backup & restore
Import config to new license via Backup & restore
Restart sniffers: systemctl restart voipmonitor

ℹ️ Note: Alert-to-sensor assignments must be reconfigured manually after migration.

Troubleshooting

Backup Fails with "errno 28" (Disk Full)

MySQL needs temp space for backup operations.

Solution: Use smaller "configuration tables" backup instead of "data tables":

Configuration tables: ~1-10 MB (contains all essential settings)
Data tables: 100+ MB (supporting data, not critical)

Check disk space: df -h (look at /tmp and /var/lib/mysql)

Backup Breaks GTID Replication

mysqldump includes GTID state by default, breaking replication on restore.

Solution: Configure mysqldump to exclude GTID:

Settings → System Configuration → Database
Set Extra parameters for mysqldump binary: --set-gtid-purged=OFF
Save and create new backup

Or manually:

mysqldump -u root -p --set-gtid-purged=OFF voipmonitor users sensors alerts custom_config > backup.sql

Alerts/Reports Missing After Upgrade

Restore from backup created before upgrade:

Tools → Backup & restore → "restore" → upload pre-upgrade backup
Reconfigure alert-to-sensor assignments manually

AI Summary for RAG

Summary: VoIPmonitor GUI configuration backup guide. Two methods: (1) GUI via Tools → Backup & restore for one-time backups, (2) CLI using backupGuiTables/restoreGuiTables commands with cron for automation. Backup includes users, sensors, alerts, dashboards, capture rules. Does NOT include: alert-to-sensor assignments, report-to-sensor assignments, CDR/PCAP data. Restore overwrites existing data. Dashboard-only migration: extract custom_config table. Server migration: fresh install recommended for EOL systems; use Redundant_database for data migration. Cloud token migration requires support intervention to restore old database to temporary license. Troubleshooting: errno 28 (disk full) - use smaller "configuration tables" backup; GTID replication - set --set-gtid-purged=OFF in mysqldump parameters.

Keywords: backup, restore, configuration, GUI settings, users, sensors, alerts, dashboards, capture rules, backupGuiTables, restoreGuiTables, custom_config, cron automation, migration, disaster recovery, cloud token, GTID replication, errno 28, disk full

Key Questions:

How do I back up VoIPmonitor GUI configuration?
How do I schedule automated daily GUI backups?
How do I restore GUI settings from backup?
What is and is not included in a GUI configuration backup?
Does restore merge or overwrite existing data?
How do I migrate only dashboards between GUI instances?
How do I migrate VoIPmonitor to a new server?
How do I transfer alerts between cloud tokens?
Why does backup fail with errno 28?
How do I prevent backups from breaking MySQL GTID replication?