Backing Up GUI Configuration: Difference between revisions

From VoIPmonitor.org
(Add IMPORTANT section clarifying what is and is NOT transferred during restore (user accounts yes, sensor assignments no, overwrite not merge))
(Rewrite: consolidated structure, removed redundancy, added quick reference table)
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{DISPLAYTITLE:Backing Up GUI Configuration}}
{{DISPLAYTITLE:Backing Up GUI Configuration}}


'''This guide provides a step-by-step method for creating regular, automated backups of your VoIPmonitor GUI's configuration. This includes users, sensors, capture rules, and all other settings configured through the web interface.'''
This guide covers backing up and restoring VoIPmonitor GUI configuration data (users, sensors, alerts, dashboards). It does '''not''' cover CDR/PCAP data backup.


== Overview ==
== Quick Reference ==
This backup procedure is designed to save '''only the GUI's configuration data''', not the call data (CDRs) or captured PCAP files. It is an essential part of a disaster recovery plan, allowing you to quickly restore a known-good GUI configuration to a new or rebuilt server without backing up terabytes of call data.


The process uses a command-line PHP script included with the GUI to export three types of data:
{| class="wikitable"
#'''Configuration Tables:''' The core database tables that store settings (e.g., `users`, `sensors`, `filter_ip`).
|-
#'''Data Tables:''' Supporting data like chart configurations and saved reports.
! Task !! Method !! Command/Path
#'''Configuration Files:''' The PHP configuration files from the GUI directory itself (e.g., `configuration.php`).
|-
| One-time backup || GUI || '''Tools → Backup & restore''' → select "configuration tables" + "configuration files"
|-
| Automated backup || CLI || <code>php run.php backupGuiTables -t config -f backup.sql</code>
|-
| Restore || GUI || '''Tools → Backup & restore''' → "restore"
|-
| Restore || CLI || <code>php run.php restoreGuiTables -t config -f backup.sql</code>
|}


== Step 1: Create the Backup Script ==
'''What Gets Backed Up:'''
First, create a shell script that will run the export commands.
* '''Configuration Tables:''' Users, sensors, capture rules, alerts, dashboards, reports
* '''Configuration Files:''' PHP config files (<code>configuration.php</code>)


;Create and edit the script file:
{{Warning|1=Restoring '''overwrites''' existing settings. Perform on fresh GUI or accept data loss.}}
<pre>
nano /usr/local/sbin/backup_voipmonitor_gui.sh
</pre>


;Copy and paste the following content into the file:
== GUI Backup (Quick Method) ==
<pre>
 
#!/bin/bash
Ideal for one-time backups before upgrades or migrations.
#
 
# VoIPmonitor GUI Configuration Backup Script
# 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


# --- Configuration ---
== Automated CLI Backup ==
# Set the base directory where backups will be stored
BACKUP_DIR="/var/backups/voipmonitor_gui"


# Set the retention period in days. Backups older than this will be deleted.
For production environments requiring scheduled backups.
RETENTION_DAYS=30


# --- Script Logic ---
=== Backup Script ===


# Create the backup directory if it doesn't exist
Create <code>/usr/local/sbin/backup_voipmonitor_gui.sh</code>:
mkdir -p "$BACKUP_DIR"


# Set the filename based on the current date
<syntaxhighlight lang="bash">
DAY=$(date "+%Y-%m-%d")
#!/bin/bash
FILE_CFG_TABLES="$BACKUP_DIR/config_tables-${DAY}.sql"
# VoIPmonitor GUI Configuration Backup Script
FILE_DATA_TABLES="$BACKUP_DIR/data_tables-${DAY}.sql"
FILE_CFG_FILES="$BACKUP_DIR/config_files-${DAY}.tar.gz"


# Path to the GUI's run.php script
BACKUP_DIR="/var/backups/voipmonitor_gui"
RETENTION_DAYS=30
RUN_SCRIPT="/var/www/html/php/run.php"
RUN_SCRIPT="/var/www/html/php/run.php"
DAY=$(date "+%Y-%m-%d")


echo "--- Starting VoIPmonitor GUI Backup for ${DAY} ---"
mkdir -p "$BACKUP_DIR"
 
# Export the configuration and data tables as SQL dumps
php "$RUN_SCRIPT" backupGuiTables -t config -f "$FILE_CFG_TABLES"
php "$RUN_SCRIPT" backupGuiTables -t data -f "$FILE_DATA_TABLES"


# Backup the GUI's PHP configuration files into a compressed tarball
# Export configuration and data tables
php "$RUN_SCRIPT" backupGuiConfigurationFiles -f "$FILE_CFG_FILES"
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"


echo "Backup files created:"
# Cleanup old backups
ls -lh "$FILE_CFG_TABLES" "$FILE_DATA_TABLES" "$FILE_CFG_FILES"
find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" \( -name '*.sql' -o -name '*.tar.gz' \) -delete


# Clean up old backups
echo "Backup complete: $BACKUP_DIR"
echo "--- Cleaning up backups older than ${RETENTION_DAYS} days ---"
</syntaxhighlight>
find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" -name '*-*-*-*.sql' -print -delete
find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" -name '*-*-*-*.tar.gz' -print -delete


echo "--- Backup complete ---"
=== Setup ===
</pre>


=== Step 2: Make the Script Executable ===
<syntaxhighlight lang="bash">
Set the correct permissions so the script can be run.
# Make executable and test
<pre>
chmod +x /usr/local/sbin/backup_voipmonitor_gui.sh
chmod +x /usr/local/sbin/backup_voipmonitor_gui.sh
</pre>
/usr/local/sbin/backup_voipmonitor_gui.sh
You can test the script by running it manually: `/usr/local/sbin/backup_voipmonitor_gui.sh`. It should create three new files in `/var/backups/voipmonitor_gui`.
 
== Step 3: Schedule the Automated Backup with Cron ==
The final step is to create a cron job to run the script automatically every night.


;Edit the system's crontab file:
# Schedule daily at 3:30 AM
<pre>
crontab -e
crontab -e
</pre>
# Add: 30 3 * * * /usr/local/sbin/backup_voipmonitor_gui.sh > /var/log/voipmonitor_backup.log 2>&1
</syntaxhighlight>


;Add the following line to the end of the file:
=== CLI Restore ===
This example will run the backup script every day at 3:30 AM.
<pre>
30 3 * * * /usr/local/sbin/backup_voipmonitor_gui.sh > /var/log/voipmonitor_backup.log 2>&1
</pre>
* The `> /var/log/voipmonitor_backup.log 2>&1` part redirects all output (both standard and error) to a log file, which is essential for troubleshooting the cron job if it fails.


Save and close the file. The cron daemon will automatically pick up the new schedule.
<syntaxhighlight lang="bash">
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


== Importing Only Dashboards from Another GUI Instance ==
# Restore config files
Use this procedure when you need to migrate dashboards from an old VoIPmonitor GUI instance to a new one without importing other configurations like sensors or capture rules.
tar xzf /var/backups/voipmonitor_gui/config_files-YYYY-MM-DD.tar.gz -C /var/www/html/
</syntaxhighlight>


Dashboards are stored in the `custom_config` database table, which is part of the configuration backup.
== What IS and IS NOT Transferred ==


=== Important Notes ===
{| class="wikitable"
* This process imports dashboards, charts, and associated reports - it is not possible to isolate only the Dashboard layouts
|-
* Folder structures will NOT be preserved - you will need to manually recreate dashboard folders after import
! Transferred !! NOT Transferred
* Dashboard ownership may need to be adjusted (e.g., to make dashboards public or assign to the correct user)
|-
* Panel caching may need to be reconfigured for imported dashboards
| 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
|}


=== Step 1: Create Backups on Both Instances ===
{{Note|1=Restore '''replaces''' data, it does NOT merge. Users/sensors with same ID are overwritten.}}


First, create backups on both the old and new GUI instances:
== Dashboard-Only Migration ==


'''Old GUI Server:'''
To transfer only dashboards between GUI instances without other settings.
<pre>
cd /var/www/html
php php/run.php backupGuiTables -t config -f /tmp/old_gui_config.sql
</pre>


'''New GUI Server:'''
=== Simple Method (GUI) ===
<pre>
cd /var/www/html
php php/run.php backupGuiTables -t config -f /tmp/new_gui_config.sql
</pre>


The backup of the new instance is useful for rollback if the import causes issues.
Use standard '''Backup & restore''' - this transfers dashboards along with other config. Users are included.


=== Step 2: Extract the custom_config Table from Old Instance ===
=== Advanced Method (SQL Extraction) ===


The `custom_config` table contains dashboard definitions. Extract only this table from the old instance's backup file:
Dashboards are stored in the <code>custom_config</code> table.


<pre>
<syntaxhighlight lang="bash">
# Extract only the custom_config table INSERT statements
# On source server: create backup
grep -A 100000 "Dumping data for table \`custom_config\`" /tmp/old_gui_config.sql | \
cd /var/www/html
grep -B 100000 "Table structure for table" | \
php php/run.php backupGuiTables -t config -f /tmp/old_config.sql
grep "^INSERT INTO" > /tmp/custom_config_only.sql
</pre>


Alternatively, you can manually extract the table by editing the SQL file and copying only the `INSERT INTO custom_config` statements.
# Extract only custom_config INSERT statements
grep "^INSERT INTO \`custom_config\`" /tmp/old_config.sql > /tmp/dashboards_only.sql


=== Step 3: Modify Dashboard Ownership (If Needed) ===
# On target server: import
mysql -u voipmonitor_user -p voipmonitor < /tmp/dashboards_only.sql
</syntaxhighlight>


The `custom_config` table may contain user-specific ownership information. If you need to adjust this, edit the `/tmp/custom_config_only.sql` file:
{{Note|Folder structures are NOT preserved. Recreate folders manually after import.}}


<pre>
== Server Migration ==
nano /tmp/custom_config_only.sql
</pre>


Common modifications:
=== Fresh Installation Method (Recommended) ===
* Change user ID values to match users on the new instance
* Set ownership to make dashboards public (if your installation supports this)
* Update any instance-specific paths or IDs


{{Note|
Best for EOL systems or when historical data is not needed.
The structure of the `custom_config` table includes fields that may reference user IDs and other instance-specific data. Review your SQL export carefully before importing to ensure data consistency.
}}


=== Step 4: Import the custom_config Table to New Instance ===
# '''Backup on old server:'''
#* GUI config: '''Tools → Backup & restore''' → "configuration tables"
#* Sniffer config: <code>cp /etc/voipmonitor.conf /tmp/</code>
#* GUI PHP config: <code>cp /var/www/html/*/configuration.php /tmp/</code>
# '''Fresh install on new server''' (see [[Sniffer_installation]], [[GUI_installation]])
# '''Restore configuration:'''
#* GUI: '''Tools → Backup & restore''' → "restore"
#* Sniffer: <code>cp voipmonitor.conf.backup /etc/voipmonitor.conf</code>
#* Update <code>interface</code>, <code>spooldir</code>, <code>server_bind</code> for new environment
# '''Update remote probes''' (if distributed): Change <code>server_destination</code> to new server IP
# '''Test with subset of traffic''' before full cutover


Import the extracted `custom_config` table into the new GUI instance:
{{Tip|1=To preserve trial license on new system, use CLI restore with <code>--exclude-table system</code>}}


<pre>
=== Data Migration Method ===
cd /var/www/html
mysql -u voipmonitor_user -p voipmonitor < /tmp/custom_config_only.sql
</pre>


Or use the GUI web interface if it provides a table import function.
For transferring historical CDR data with minimal downtime. See [[Redundant_database]] for:
* '''Dump/Restore:''' Simple <code>mysqldump</code> with downtime
* '''Online Migration:''' Use <code>voipmonitor-migrate.conf</code> for zero-downtime sync


=== Step 5: Post-Import Tasks ===
=== Cross-OS / Cloud Migration ===


After importing the dashboards, you will need to:
{{Warning|1=Do NOT clone binaries between different OS versions. Always perform fresh installation.}}


;Recreate Dashboard Folder Structures:
* Download GUI package matching destination PHP version (see [[Re-install_the_GUI]])
The import does not preserve folder hierarchies. Log in to the new GUI and manually create any dashboard folders, then move imported dashboards into the appropriate folders.
* For database version mismatches, use migration instance instead of direct mysqldump


;Configure Panel Caching:
== Cloud Token Migration ==
If your dashboards use cached data for performance, you may need to reconfigure panel caching settings for the imported dashboards.


;Verify Permissions:
Each cloud token has its own database. To migrate alerts/reports between tokens:
Check that users who should have access to the dashboards are appropriately configured in the new GUI instance.


=== Troubleshooting ===
# '''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:''' <code>systemctl restart voipmonitor</code>


If dashboards do not appear after import:
{{Note|Alert-to-sensor assignments must be reconfigured manually after migration.}}
* Verify the `custom_config` table was imported correctly by checking the database
* Check for user ID mismatches between the old and new instances
* Clear browser cache and refresh the GUI
* Review any GUI error logs for related messages


== How to Restore from a Backup ==
== Troubleshooting ==
There are two methods to restore your GUI configuration: the recommended CLI method or the manual method.


'''Warning:''' This process will overwrite your existing GUI settings. Perform these steps on a freshly installed GUI or be prepared to lose current configurations.
=== Backup Fails with "errno 28" (Disk Full) ===


=== IMPORTANT: What IS and IS NOT Transferred ===
MySQL needs temp space for backup operations.


When restoring a GUI configuration backup to a new instance, the following applies:
'''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)


;What IS Transferred:
Check disk space: <code>df -h</code> (look at <code>/tmp</code> and <code>/var/lib/mysql</code>)
* User accounts (login credentials, user IDs)
* Permissions and user group assignments
* User settings and preferences
* Sensor definitions (sensor names, IP addresses, capture rules)
* Alert definitions and thresholds
* Filter configurations
* Dashboard configurations


;What is NOT Transferred:
=== Backup Breaks GTID Replication ===
* '''Assignments of alerts to sensors''' - These must be reconfigured manually after restore
* '''Assignments of reports to sensors''' - These must be reconfigured manually after restore
* '''Sensor user assignments''' - Access permissions for sensors must be reassigned to users
* Captured call data (CDRs) and PCAP files - These are not included in the backup


;Behavior When Merging:
mysqldump includes GTID state by default, breaking replication on restore.
If the new GUI instance already has existing data:
* User accounts from the backup will '''overwrite''' existing users with the same username or ID
* Sensor definitions will be replaced with the backed-up versions
* Configuration settings will be overwritten
* This is NOT a merge operation - it is a restore that replaces existing data


For these reasons, it is strongly recommended to perform the restore on a freshly installed GUI instance with no existing configuration.
'''Solution:''' Configure mysqldump to exclude GTID:
# '''Settings → System Configuration → Database'''
# Set '''Extra parameters for mysqldump binary:''' <code>--set-gtid-purged=OFF</code>
# Save and create new backup


=== Method 1: Using the restoreGuiTables CLI Command (Recommended) ===
Or manually:
The GUI provides a command-line tool to restore configuration tables directly without manually importing SQL files.
<syntaxhighlight lang="bash">
mysqldump -u root -p --set-gtid-purged=OFF voipmonitor users sensors alerts custom_config > backup.sql
</syntaxhighlight>


;1. Navigate to your GUI directory:
=== Alerts/Reports Missing After Upgrade ===
<pre>
cd /var/www/html
</pre>


;2. Restore the configuration tables:
Restore from backup created before upgrade:
<pre>
# '''Tools → Backup & restore''' → "restore" → upload pre-upgrade backup
php php/run.php restoreGuiTables -t config -f /var/backups/voipmonitor_gui/config_tables-YYYY-MM-DD.sql
# Reconfigure alert-to-sensor assignments manually
php php/run.php restoreGuiTables -t data -f /var/backups/voipmonitor_gui/data_tables-YYYY-MM-DD.sql
</pre>


;3. Restore the Configuration Files:
== See Also ==
Extract the backed-up PHP configuration files into your GUI's web root.
<pre>
# Extract the archive, overwriting existing files
tar xzf /var/backups/voipmonitor_gui/config_files-YYYY-MM-DD.tar.gz
</pre>


=== Method 2: Manual MySQL Import ===
* [[Redundant_database]] - Database replication and online migration
Alternatively, you can use the `mysql` command-line client to import the saved SQL dumps.
* [[Re-install_the_GUI]] - GUI reinstallation for PHP version changes
* [[Disaster_Recovery]] - Complete disaster recovery procedures
* [[Data_Cleaning]] - Disk space management


;1. Restore the Database Tables:
== AI Summary for RAG ==
<pre>
mysql -u your_user -p voipmonitor < /var/backups/voipmonitor_gui/config_tables-YYYY-MM-DD.sql
mysql -u your_user -p voipmonitor < /var/backups/voipmonitor_gui/data_tables-YYYY-MM-DD.sql
</pre>


;2. Restore the Configuration Files:
'''Summary:''' VoIPmonitor GUI configuration backup guide. Two methods: (1) GUI via '''Tools → Backup & restore''' for one-time backups, (2) CLI using <code>backupGuiTables</code>/<code>restoreGuiTables</code> 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 <code>custom_config</code> 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 <code>--set-gtid-purged=OFF</code> in mysqldump parameters.
Extract the backed-up PHP configuration files into your GUI's web root.
<pre>
# Navigate to the GUI's root directory (path may vary)
cd /var/www/html/


# Extract the archive, overwriting existing files
'''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
tar xzf /var/backups/voipmonitor_gui/config_files-YYYY-MM-DD.tar.gz
</pre>


After restoring both the database and files, your GUI's configuration should be fully recovered.
== AI Summary for RAG ==
'''Summary:''' This guide provides a comprehensive, step-by-step method for creating automated daily backups of the VoIPmonitor GUI configuration. It clarifies that this process backs up settings, users, and rules, but not the call data (CDRs) or PCAP files. The core of the guide is a robust shell script that uses the GUI's built-in `run.php` command-line tool to export configuration tables, data tables, and PHP configuration files. The provided script also includes an automated cleanup feature to delete backups older than a configurable number of days. The tutorial details how to create this script, make it executable, and schedule it to run daily using a system cron job. The guide includes two restoration methods: the recommended CLI method using `restoreGuiTables` command and the manual method using `mysql` import. Additional critical information specifies what is and is not transferred during restore: user accounts and sensor definitions are transferred, but assignments of alerts to sensors, reports to sensors, and sensor user access permissions are NOT transferred and must be manually reconfigured. The restore operation overwrites, not merges, existing data. The guide also covers a specialized procedure for importing only dashboards from one GUI instance to another by extracting and importing the `custom_config` table, including important caveats about folder structure preservation and ownership adjustments.
'''Keywords:''' backup, restore, configuration, gui, settings, users, sensors, capture rules, cron, crontab, automation, disaster recovery, dashboard, migration, `run.php`, `backupGuiTables`, `restoreGuiTables`, `backupGuiConfigurationFiles`, mysql, import, export, custom_config, overwrite, merge, assignment, not transferred
'''Key Questions:'''
'''Key Questions:'''
* How do I back up my VoIPmonitor GUI configuration?
* How do I back up VoIPmonitor GUI configuration?
* How can I save all my users, sensors, and settings?
* How do I schedule automated daily GUI backups?
* Is there a script to automatically back up VoIPmonitor settings?
* How do I restore GUI settings from backup?
* How do I schedule a daily backup using cron?
* What is and is not included in a GUI configuration backup?
* How do I restore my GUI configuration from a backup?
* Does restore merge or overwrite existing data?
* What does the `backupGuiTables` command do?
* How do I migrate only dashboards between GUI instances?
* What does the `restoreGuiTables` command do?
* How do I migrate VoIPmonitor to a new server?
* Does this backup include my call recordings (CDRs/PCAPs)?
* How do I transfer alerts between cloud tokens?
* How do I import only dashboards from one GUI to another without importing sensors or filters?
* Why does backup fail with errno 28?
* Which table contains dashboard configurations in VoIPmonitor?
* How do I prevent backups from breaking MySQL GTID replication?
* How do I extract only the custom_config table from a GUI backup?
* Are sensor assignments preserved during restore?
* Do I need to reconfigure alert to sensor assignments after migration?
* Does the restore merge or overwrite existing data?
* Can I transfer user accounts to a new VoIPmonitor instance?

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.

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

To Restore:

  1. Navigate to GUI → Tools → Backup & restore
  2. Select "restore"
  3. 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.

  1. 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/
  2. Fresh install on new server (see Sniffer_installation, GUI_installation)
  3. Restore configuration:
    • GUI: Tools → Backup & restore → "restore"
    • Sniffer: cp voipmonitor.conf.backup /etc/voipmonitor.conf
    • Update interface, spooldir, server_bind for new environment
  4. Update remote probes (if distributed): Change server_destination to new server IP
  5. 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:

  1. Contact VoIPmonitor support - request temporary trial cloud license
  2. Support restores old database to temporary license
  3. Export config from temporary license via Backup & restore
  4. Import config to new license via Backup & restore
  5. 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:

  1. Settings → System Configuration → Database
  2. Set Extra parameters for mysqldump binary: --set-gtid-purged=OFF
  3. 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:

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

See Also

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?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Backing_Up_GUI_Configuration&oldid=10087"