Disaster Recovery: Difference between revisions

From VoIPmonitor.org
(Add disaster recovery guide for disk failure scenarios)
 
(Rewrite: fixed syntax errors, improved structure, added workflow diagram, consolidated content)
 
Line 1: Line 1:
{{DISPLAYTITLE:Disaster Recovery}}
{{DISPLAYTITLE:Disaster Recovery}}


'''This guide describes the recovery process when a VoIPmonitor server experiences a disk failure requiring full operating system and application reinstallation. This applies to sniffer servers, GUI servers, and all-in-one deployments.'''
'''Recovery procedure after disk failure requiring OS and VoIPmonitor reinstallation.'''


== Overview ==
== Overview ==


When a disk fails and requires replacement, the recovery process involves coordination between you (the customer) and VoIPmonitor support staff. This is not a self-service procedure - VoIPmonitor support will handle the actual VoIPmonitor installation and configuration after you prepare the system.
When a disk fails and requires replacement, recovery involves:
 
# '''Customer:''' Replace hardware, install OS, configure network, provide remote access
# '''Support:''' Install VoIPmonitor, restore configuration, verify operation
 
{{Note|Self-service installation is possible using [[Sniffer_installation|Sniffer Installation]] and [[GUI_installation|GUI Installation]] guides if you have VoIPmonitor expertise.}}
 
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 25}}}%%
flowchart LR
    A[Disk Failure] --> B[Replace Hardware]
    B --> C[Install OS]
    C --> D[Configure Network]
    D --> E[Set Timezone]
    E --> F[Provide Remote Access]
    F --> G[Support Installs VoIPmonitor]
    G --> H{Backups Available?}
    H -->|Yes| I[Restore Data]
    H -->|No| J[Start Fresh]
    I --> K[Verify Services]
    J --> K
</kroki>
 
== Step 1: Hardware & OS ==
 
Replace failed disks and install a supported OS:


{| class="wikitable"
{| class="wikitable"
|-
|-
! colspan="2" style="background: #856404; color: white;" | Key Concept: Support-Coordinated Recovery
! OS !! Status
|-
|-
! Customer Tasks
| Ubuntu 24.04 LTS || '''Recommended'''
| Replace failed disks, install operating system, provide remote access
|-
|-
! Support Tasks
| Debian 12/13 || Supported
| Install VoIPmonitor, configure database connection, restore configuration
|-
| Rocky Linux 9/10 || Supported
|-
| CentOS 7 || EOL - migrate to Rocky/Alma
|}
|}


This approach ensures the system is properly configured and minimizes downtime. However, you can perform some components yourself if you have the necessary expertise.
{{Warning|1=Do not copy binaries from old disk if OS version differs. Always install VoIPmonitor fresh using the official installer.}}
 
== Recovery Workflow ==
 
The recovery process consists of these phases:
 
=== Step 1: Hardware Replacement ===
 
Replace the failed physical disks on the server with new disks of adequate capacity.
 
{{Note|Disk capacity should be at least equal to or greater than the original disks, especially if you plan to restore PCAP data from backups.}}
 
=== Step 2: Operating System Installation ===
 
Install a supported operating system on the new disks. Common choices include:
 
* '''Ubuntu 24.04 LTS''' (recommended for new deployments)
* '''Debian 12 (Bookworm)'''
* '''Rocky Linux 9**
* '''CentOS 7.2** (older systems, see migration notes)


{{Warning|Do not attempt to copy binaries from the old disk if the OS version differs significantly. Always install VoIPmonitor from scratch using the official installer for the new OS.}}
== Step 2: Network Configuration ==


=== Step 3: Network Configuration ===
Configure network interfaces to match original server:
* Same IP address (for fixed configurations)
* DNS servers and routing
* SPAN/TAP port connectivity (for sniffer servers)


Configure the network interfaces to match the original server's configuration:
== Step 3: Timezone Configuration ==


* Set the same IP address (if required for fixed network configuration)
{{Warning|1='''CRITICAL:''' PCAP paths use local time (<code>/var/spool/voipmonitor/YYYY/MM/DD</code>). Timezone mismatch prevents GUI from finding historical recordings.}}
* Configure DNS servers
* Ensure proper routing
 
This is critical for：
* Remote access for support staff
* Connection to central database/GUI servers (for distributed deployments)
* SPAN/TAP port configuration (for sniffer servers)
 
=== Step 4: Timezone Configuration (CRITICAL) ===
 
Ensure the new server's timezone matches the old server exactly.
 
{| class="wikitable" style="background-color: #FFEAA7;"
|-
! colspan="2" style="background: #D68910;" | Why Is This Critical?
|-
! Problem
| PCAP file paths in VoIPmonitor are based on the local OS time. A timezone mismatch will prevent the GUI from finding historical recordings. The spooldir follows the format <code>/var/spool/voipmonitor/YYYY/MM/DD</code> based on local time.
|-
! Solution
| Match the original timezone exactly before starting capture or restore operations.
|}


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
Line 73: Line 62:
timedatectl
timedatectl


# Set timezone (example: Europe/Prague)
# Set timezone (must match original server)
sudo timedatectl set-timezone Europe/Prague
sudo timedatectl set-timezone Europe/Prague


# Verify timezone is set correctly
# Verify
timedatectl
timedatectl
</syntaxhighlight>
</syntaxhighlight>


=== Step 5: Provide Remote Access to Support Staff ===
== Step 4: Provide Remote Access ==
 
Arrange remote access for VoIPmonitor support staff to perform the VoIPmonitor installation. Choose one of the following methods:
 
{{Note|If you have internal IT staff with VoIPmonitor expertise, you can perform the installation yourself using the standard [[Sniffer_installation|Sniffer Installation Guide]] or [[GUI_Installation|GUI Installation Guide]].}}
 
==== Method 1: SSH Access ===


Provide direct SSH access to the server:
Choose one method for VoIPmonitor support staff:


* Create a dedicated support user account (optional but recommended)
=== Method A: Direct SSH ===
* Alternatively, provide temporary root access
* Disable password authentication and use SSH keys for security


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Create support user (optional)
# Create support user (optional but recommended)
adduser supportuser
adduser supportuser
usermod -aG sudo supportuser
usermod -aG sudo supportuser


# Ensure SSH is running
# Verify SSH is running
systemctl status sshd # or ssh service name depending on OS
systemctl status sshd
</syntaxhighlight>
</syntaxhighlight>


==== Method 2: VPN Access ===
=== Method B: VPN Access ===


If your network uses a VPN, add VoIPmonitor support staff to the VPN configuration and provide:
Provide VPN credentials and server internal IP.


* VPN connection details
=== Method C: Reverse SSH Tunnel ===
* Server internal IP address
* Any required authentication


==== Method 3: Reverse SSH Tunnel ===
For servers behind firewalls without direct SSH access:


If the server is behind a firewall and does not have direct SSH access from the internet, set up a reverse SSH tunnel:
<syntaxhighlight lang="bash">
 
# Run on your internal server (connects to your bastion host)
`syntaxhighlight lang="bash">`
# On a server that has inbound SSH access (e.g., your bastion host)
# This command allows support to connect via the bastion to your server
 
# From your internal server (run this command):
ssh -R 2222:localhost:22 -N support@bastion.yourdomain.com
ssh -R 2222:localhost:22 -N support@bastion.yourdomain.com


# VoIPmonitor support can now connect by SSHing to bastion.yourdomain.com:2222
# Support connects via: ssh -p 2222 user@bastion.yourdomain.com
`</syntaxhighlight>`
</syntaxhighlight>


== Step 5: VoIPmonitor Installation ==


=== Step 6: VoIPmonitor Installation by Support Staff ===
Support staff will install and configure based on deployment type:


VoIPmonitor support staff will perform the following tasks:
{| class="wikitable"
|-
! Deployment Type !! Tasks
|-
| '''Sniffer-Only''' || Install binary, configure interface, connect to central server, restore <code>voipmonitor.conf</code>
|-
| '''GUI/Database''' || Install MariaDB/MySQL, GUI, PHP dependencies, restore configuration
|-
| '''All-in-One''' || All of the above, reconstruct database from PCAPs if needed
|}


==== For Sniffer Servers (Distributed Mode) ===
== Step 6: Data Recovery ==


1. Install VoIPmonitor sniffer binary
=== Case 1: Database Backup Available ===
2. Configure network interface for packet captureSPAN, TAP, or mirror port)
3. Connect sniffer to the central database/GUI server
4. Restore `voipmonitor.conf` configuration or recreate from documentation
5. Capture rules and sensor settings
6. Start the service and verify connectivity


==== For GUI/Database Servers ===
<syntaxhighlight lang="bash">
# Restore from mysqldump
gunzip < backup.sql.gz | mysql -u root -p voipmonitor
</syntaxhighlight>


1. Install MariaDB/MySQL database
For GUI configuration restore, see [[Backing_Up_GUI_Configuration#Restore|Backup & Restore Guide]].
2. Install VoIPmonitor web GUI
3. Install PHP dependencies
4. Restore GUI configuration from backups if available
5. Restore database if backups exist
6. Start services and verify web interface


==== For All-in-One Servers ===
=== Case 2: PCAP Files Survived ===


1. Install sniffer, GUI, and database components
If PCAPs can be recovered from separate storage or mounted old disk:
2. Restore full configuration from backups
3. Reconstruct database from PCAP files if backups are unavailable (see below)
4. Verify all components are functioning


=== Step 7: Restore Data (If Available) ===
<syntaxhighlight lang="bash">
 
# 1. Restore PCAP files to spooldir
Data recovery depends on what backups or recoverable PCAP files you have.
 
==== Case 1: Database Backups Available ===
 
If you have database backups from a [[Backing_Up_GUI_Configuration|backup procedure]] or mysqldump:
 
1. Restore database using <code>mysql</code> command-line client
2. Verify restored data integrity
3. Check that GUI connects to database correctly
 
`syntaxhighlight lang="bash">`
# Restore from mysqldump backup
mysql -u root -p voipmonitor < /path/to/backup.sql
`</syntaxhighlight>`
 
 
==== Case 2: PCAP Files Survived, Database Lost ===
 
If the disk failed but PCAP files can be recovered (e.g., from a separate storage volume or mounted old disk), you can reconstruct the database by processing the PCAP files.
 
{syntaxhighlight lang="bash">`
# 1. Restore PCAP files to the spooldir
rsync -avz /mnt/old_disk/var/spool/voipmonitor/ /var/spool/voipmonitor/
rsync -avz /mnt/old_disk/var/spool/voipmonitor/ /var/spool/voipmonitor/


# 2. Ensure database server is running with a fresh database
# 2. Create fresh database
mysql -e "CREATE DATABASE voipmonitor;"
mysql -e "CREATE DATABASE voipmonitor;"


# 3. Restore GUI configuration first (if available)
# 3. Restore GUI configuration first (if available)
# This ensures users, sensors, and settings are in place before processing PCAPs
# See: Backing_Up_GUI_Configuration


# 4. Run sniffer in restore mode to rebuild database from PCAPs
# 4. Reconstruct database from PCAPs
voipmonitor --config-file=/etc/voipmonitor.conf --readpcapdir /var/spool/voipmonitor
voipmonitor --config-file=/etc/voipmonitor.conf --readpcapdir /var/spool/voipmonitor
`</syntaxhighlight>`
</syntaxhighlight>


{{Note|1=Processing PCAP files in restore mode can take '''significant time''' depending on data volume. The duration scales with number of calls and PCAP file sizes.}}
{{Note|1=Processing PCAPs in restore mode can take '''significant time''' depending on data volume.}}


If the disk is completely destroyed without backups:
=== Case 3: No Backups ===
* Historical PCAP data is '''PERMANENTLY LOST'''
* CDRs and call recordings cannot be recovered
* Only configuration can be restored from backups


==== Case 3: No Backups, No Recoverable Data ===
* Historical data is '''permanently lost'''
 
If all data was on the failed disk and no backups exist:
* All historical data is permanently lost
* System must be reconfigured from scratch
* System must be reconfigured from scratch
* Ensure proper backups are implemented after recovery (see Prevention section below)
* Implement backup strategy (see Prevention below)


=== Step 8: Service Verification ===
== Step 7: Verification ==


After installation and restore operations, verify all services are running correctly.
<syntaxhighlight lang="bash">
 
# Check service status
`syntaxhighlight lang="bash">`
# Check VoIPmonitor service status
systemctl status voipmonitor
systemctl status voipmonitor


# Check web GUI service (if applicable)
# View logs
systemctl status apache2  # or nginx, depending on configuration
 
# View service logs for errors
journalctl -u voipmonitor -f
journalctl -u voipmonitor -f
tail -f /var/log/voipmonitor.log
`</syntaxhighlight>`


Verify in the GUI:
# For GUI server
* Sensors appear as connected (for distributed mode)
systemctl status apache2  # or nginx
* New calls are being captured
</syntaxhighlight>
* Historical recordings appear (if restored)
* Reports and dashboards work correctly


== Self-Service Installation (Advanced) ===
Verify in GUI:
* Sensors connected (distributed mode)
* New calls being captured
* Historical recordings accessible (if restored)


If you have VoIPmonitor expertise and prefer to perform the installation yourself, follow these guides:
== Prevention ==


* [[Sniffer_installation|Sniffer Installation Guide]]
Implement these measures to minimize future data loss:
* [[GUI_Installation|GUI Installation Guide]]
* [[Sniffer_configuration|Sniffer Configuration Reference]]
* [[Backing_Up_GUI_Configuration|Backup and Restore Guide]]


{{Warning|1=Incorrect configuration can cause data loss or monitoring gaps. If unsure, contact VoIPmonitor support for assistance.}}
{| class="wikitable"
 
== Recovery by Deployment Type ==
 
=== Sniffer-Only (Client Mode) Recovery ===
 
In distributed deployments where the sniffer sends data to a remote central server:
 
{|
|-
|-
! !! Recovery Complexity !! Key Tasks
! Measure !! Description !! Reference
|-
|-
! Data Loss
| '''GUI Backups''' || Daily automated backup of configuration, users, alerts || [[Backing_Up_GUI_Configuration]]
| '''LOW''' (typically)
| PCAPs usually stored separately or on central server
|-
|-
! Configuration
| '''Separate PCAP Storage''' || Move <code>spooldir</code> to NAS/SAN/separate disk || [[Data_Cleaning#Moving_Spooldir|Data Cleaning]]
| '''MEDIUM'''
| Restore `voipmonitor.conf`, capture rules, sensor name
|-
|-
! Network
| '''Database Replication''' || Master-master or dual-write for HA || [[Redundant_database]]
| '''HIGH'''
| Must reconnect to central database/GUI server
|}
 
{syntaxhighlight lang="bash">`
# Critical parameters for sniffer-only recovery
 
interface = eth0  # Network interface for packet capture
name_sensor = SensorName  # Must match GUI sensor configuration
 
# Connection to central server
server_destination = central.server.ip
server_destination_port = 60024
`</syntaxhighlight>`
 
 
=== All-in-One Server Recovery ===
 
When sniffer, GUI, and database were all on the failed disk:
 
{|
|-
!! Recovery Complexity !! Key Tasks
|-
! Data Loss
| '''Potentially SEVERE'''
| All data (CDRs, PCAPs, config) on same disk
|-
|-
! Configuration
| '''Database Backups''' || Regular mysqldump to off-site storage || See below
| '''HIGH'''
| Must restore/recreate all components
|-
|-
! Reconstruction
| '''Disk Health Monitoring''' || SMART monitoring for early warning || See below
| '''POSSIBLE''' (if PCAPs survive)
| Regenerate database from PCAP files
|}
|}


For all-in-one scenarios, prioritize data recovery:
=== Database Backup Cron ===


1. Attempt to mount old disk and extract PCAP files
<syntaxhighlight lang="bash">
2. If successful, reconstruct database (see case 2 above)
# /etc/cron.d/voipmonitor-backup
3. If unsuccessful, start fresh and monitor going forward
0 2 * * * root mysqldump -u root -pPASSWORD voipmonitor | gzip > /backup/db_$(date +\%Y\%m\%d).sql.gz
</syntaxhighlight>


== Prevention: Future Disaster Recovery ===
=== Disk Health Monitoring ===


To minimize impact of future disk failures, implement the following:
<syntaxhighlight lang="bash">
# Install smartmontools
apt-get install smartmontools


1. **Automated GUI Backups**
  Follow the [[Backing_Up_GUI_Configuration| GUI Automated Backup Guide]] to schedule daily backups of configuration, users, sensors, alerts, and dashboards.
2. **Separate PCAP Storage**
  Move `/var/spool/voipmonitor` to a NAS, SAN, or separate physical disk that survives OS disk failures.
3. **Database Replication**
  Set up redundant using [[Redundant_database|database replication]] for high availability.
4. **Database Backups**
  Schedule regular mysqldump backups and store them off-site.
{syntaxhighlight lang="bash">`
# Example cron job for daily database backup
0 2 * * * mysqldump -u root -pPASSWORD voipmonitor | gzip > /backup/db_backup_$(date +\%Y\%m\%d).sql.gz
`</syntaxhighlight>`
5. **Monitor Disk Health**
  Use SMART tools to monitor disk health and predict failures before they occur.
{syntaxhighlight lang="bash">`
# Check disk SMART status
# Check disk SMART status
smartctl -a /dev/sda
smartctl -a /dev/sda
</syntaxhighlight>


# Install smartmontools if not available
== See Also ==
apt-get install smartmontools
`</syntaxhighlight>`
 
=== Summary for Self-Service vs Support-Managed Recovery ===


{|
* [[Sniffer_installation|Sniffer Installation]]
|-
* [[GUI_installation|GUI Installation]]
! !! Self-Service !! Support-Managed
* [[Backing_Up_GUI_Configuration|Backup & Restore]]
|-
* [[Redundant_database|Database Redundancy]]
! Advantages
* [[Recovering_corrupted_database_tables|Database Recovery]]
| Faster if you have expertise, no coordination needed | Expert installation, proper configuration, reduced errors
|-
! Disadvantages
| Requires VoIPmonitor knowledge, risk of misconfiguration | Requires coordination, scheduling
|-
! Recommended For
| Experienced IT staff, simple deployments | Production environments, complex setups, data recovery
|}


== AI Summary for RAG ==
== AI Summary for RAG ==


'''Summary:''' Disaster recovery workflow after disk failure. Customer replaces hardware, installs OS (Ubuntu 24.04, Debian 12, Rocky 8/9, CentOS 7.2), configures network, sets timezone (critical for PCAP path matching), provides remote access to VoIPmonitor support (SSH, VPN, or reverse SSH tunnel). Support staff installs VoIPmonitor components, connects to database/GUI, restores configuration. Recovery scenarios: sniffer-only (low data loss, reconnect to central), all-in-one (potentially severe data loss, reconstruct database from PCAPs if available). Data recovery options: (1) Database backups, restore via mysql/mysqldump. (2) PCAP files survive: use <code>voipmonitor --readpcapdir /var/spool/voipmonitor</code> to reconstruct CDRs from PCAPs, can take significant time based on data volume. (3) No backups: data permanently lost, reconfigure from scratch. Prevention: automated GUI backups via [[Backing_Up_GUI_Configuration|Backing_Up_GUI_Configuration]], separate PCAP storage, database replication via [[Redundant_database|Redundant_database]], regular mysqldump, use smartctl for disk health monitoring. Self-service possible if you have VoIPmonitor expertise, use [[Sniffer_installation|Sniffer Installation Guide]].
'''Summary:''' Disaster recovery procedure after VoIPmonitor server disk failure. Workflow: (1) Replace hardware; (2) Install supported OS (Ubuntu 24.04, Debian 12/13, Rocky Linux 9/10 recommended); (3) Configure network to match original; (4) Set timezone - CRITICAL because PCAP paths use local time format <code>/var/spool/voipmonitor/YYYY/MM/DD</code>; (5) Provide remote access to support (SSH, VPN, or reverse tunnel); (6) Support installs VoIPmonitor. Data recovery options: database backup restore via mysqldump, PCAP reconstruction using <code>voipmonitor --readpcapdir /var/spool/voipmonitor</code>, or start fresh if no backups. Prevention: automated GUI backups, separate PCAP storage on NAS/SAN, database replication, regular mysqldump, SMART disk monitoring.


'''Keywords:''' disaster recovery, disk failure, data recovery, OS reinstall, remote access, SSH, VPN, reverse SSH tunnel, timezone settings, PCAP restoration, database reconstruction, spooldir, voipmonitor.conf, all-in-one, distributed mode, database backup, mysqldump, smartctl, prevention, NAS, SAN, high availability
'''Keywords:''' disaster recovery, disk failure, data recovery, OS reinstall, timezone configuration, PCAP restoration, database reconstruction, readpcapdir, spooldir, remote access, SSH tunnel, reverse tunnel, VPN, mysqldump, smartctl, backup strategy, NAS, SAN, high availability


'''Key Questions:'''
'''Key Questions:'''
* What do I do after a disk failure on my VoIPmonitor server?
* What do I do after a disk failure on my VoIPmonitor server?
* How do I recover VoIPmonitor after a complete disk failure?
* How do I recover VoIPmonitor after complete disk failure?
* Do I need VoIPmonitor support for disaster recovery?
* Why is timezone critical after disk failure recovery?
* What information do I need to provide to support staff after a disk failure?
* How do I provide remote access to VoIPmonitor support?
* What are the steps for providing remote access to support staff (SSH, VPN, reverse tunnel)?
* How do I reconstruct VoIPmonitor database from PCAP files?
* Why is timezone configuration critical after disk failure?
* Can I recover PCAP files if the database is lost?
* Can I recover my PCAP files if the disk failed?
* What backups should I have for disaster recovery?
* How do I reconstruct the VoIPmonitor database from PCAP files?
* How do I set up a reverse SSH tunnel for support access?
* What is the difference between sniffer-only and all-in-one recovery?
* How can I prevent data loss from future disk failures?
* What backups should I have in place for disaster recovery?
* Should I attempt self-service recovery or wait for support?

Latest revision as of 16:49, 8 January 2026


Recovery procedure after disk failure requiring OS and VoIPmonitor reinstallation.

Overview

When a disk fails and requires replacement, recovery involves:

  1. Customer: Replace hardware, install OS, configure network, provide remote access
  2. Support: Install VoIPmonitor, restore configuration, verify operation

ℹ️ Note: Self-service installation is possible using Sniffer Installation and GUI Installation guides if you have VoIPmonitor expertise.

Step 1: Hardware & OS

Replace failed disks and install a supported OS:

OS Status
Ubuntu 24.04 LTS Recommended
Debian 12/13 Supported
Rocky Linux 9/10 Supported
CentOS 7 EOL - migrate to Rocky/Alma

⚠️ Warning: Do not copy binaries from old disk if OS version differs. Always install VoIPmonitor fresh using the official installer.

Step 2: Network Configuration

Configure network interfaces to match original server:

  • Same IP address (for fixed configurations)
  • DNS servers and routing
  • SPAN/TAP port connectivity (for sniffer servers)

Step 3: Timezone Configuration

⚠️ Warning: CRITICAL: PCAP paths use local time (/var/spool/voipmonitor/YYYY/MM/DD). Timezone mismatch prevents GUI from finding historical recordings. 

# Check current timezone
timedatectl

# Set timezone (must match original server)
sudo timedatectl set-timezone Europe/Prague

# Verify
timedatectl

Step 4: Provide Remote Access

Choose one method for VoIPmonitor support staff:

Method A: Direct SSH

# Create support user (optional but recommended)
adduser supportuser
usermod -aG sudo supportuser

# Verify SSH is running
systemctl status sshd

Method B: VPN Access

Provide VPN credentials and server internal IP.

Method C: Reverse SSH Tunnel

For servers behind firewalls without direct SSH access: 

# Run on your internal server (connects to your bastion host)
ssh -R 2222:localhost:22 -N support@bastion.yourdomain.com

# Support connects via: ssh -p 2222 user@bastion.yourdomain.com

Step 5: VoIPmonitor Installation

Support staff will install and configure based on deployment type:

Deployment Type Tasks
Sniffer-Only Install binary, configure interface, connect to central server, restore voipmonitor.conf
GUI/Database Install MariaDB/MySQL, GUI, PHP dependencies, restore configuration
All-in-One All of the above, reconstruct database from PCAPs if needed

Step 6: Data Recovery

Case 1: Database Backup Available

# Restore from mysqldump
gunzip < backup.sql.gz | mysql -u root -p voipmonitor

For GUI configuration restore, see Backup & Restore Guide.

Case 2: PCAP Files Survived

If PCAPs can be recovered from separate storage or mounted old disk: 

# 1. Restore PCAP files to spooldir
rsync -avz /mnt/old_disk/var/spool/voipmonitor/ /var/spool/voipmonitor/

# 2. Create fresh database
mysql -e "CREATE DATABASE voipmonitor;"

# 3. Restore GUI configuration first (if available)
# See: Backing_Up_GUI_Configuration

# 4. Reconstruct database from PCAPs
voipmonitor --config-file=/etc/voipmonitor.conf --readpcapdir /var/spool/voipmonitor

ℹ️ Note: Processing PCAPs in restore mode can take significant time depending on data volume.

Case 3: No Backups

  • Historical data is permanently lost
  • System must be reconfigured from scratch
  • Implement backup strategy (see Prevention below)

Step 7: Verification

# Check service status
systemctl status voipmonitor

# View logs
journalctl -u voipmonitor -f

# For GUI server
systemctl status apache2  # or nginx

Verify in GUI:

  • Sensors connected (distributed mode)
  • New calls being captured
  • Historical recordings accessible (if restored)

Prevention

Implement these measures to minimize future data loss:

Measure Description Reference
GUI Backups Daily automated backup of configuration, users, alerts Backing_Up_GUI_Configuration
Separate PCAP Storage Move spooldir to NAS/SAN/separate disk Data Cleaning
Database Replication Master-master or dual-write for HA Redundant_database
Database Backups Regular mysqldump to off-site storage See below
Disk Health Monitoring SMART monitoring for early warning See below

Database Backup Cron

# /etc/cron.d/voipmonitor-backup
0 2 * * * root mysqldump -u root -pPASSWORD voipmonitor | gzip > /backup/db_$(date +\%Y\%m\%d).sql.gz

Disk Health Monitoring

# Install smartmontools
apt-get install smartmontools

# Check disk SMART status
smartctl -a /dev/sda

See Also

AI Summary for RAG

Summary: Disaster recovery procedure after VoIPmonitor server disk failure. Workflow: (1) Replace hardware; (2) Install supported OS (Ubuntu 24.04, Debian 12/13, Rocky Linux 9/10 recommended); (3) Configure network to match original; (4) Set timezone - CRITICAL because PCAP paths use local time format /var/spool/voipmonitor/YYYY/MM/DD; (5) Provide remote access to support (SSH, VPN, or reverse tunnel); (6) Support installs VoIPmonitor. Data recovery options: database backup restore via mysqldump, PCAP reconstruction using voipmonitor --readpcapdir /var/spool/voipmonitor, or start fresh if no backups. Prevention: automated GUI backups, separate PCAP storage on NAS/SAN, database replication, regular mysqldump, SMART disk monitoring.

Keywords: disaster recovery, disk failure, data recovery, OS reinstall, timezone configuration, PCAP restoration, database reconstruction, readpcapdir, spooldir, remote access, SSH tunnel, reverse tunnel, VPN, mysqldump, smartctl, backup strategy, NAS, SAN, high availability

Key Questions:

  • What do I do after a disk failure on my VoIPmonitor server?
  • How do I recover VoIPmonitor after complete disk failure?
  • Why is timezone critical after disk failure recovery?
  • How do I provide remote access to VoIPmonitor support?
  • How do I reconstruct VoIPmonitor database from PCAP files?
  • Can I recover PCAP files if the database is lost?
  • What backups should I have for disaster recovery?
  • How do I set up a reverse SSH tunnel for support access?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Disaster_Recovery&oldid=10159"