VOS3000 Disaster Recovery & Backup Setup: Master‑Slave High Availability Important Guide

In the VoIP business, downtime means lost revenue and angry customers. A proper VOS3000 disaster recovery plan ensures that your softswitch keeps running even if the primary server fails. Whether you’re serving hundreds or thousands of concurrent calls, a master‑slave high availability (HA) setup is the industry standard for reliability.

In this guide, we’ll walk you through the complete process of configuring VOS3000 disaster recovery, including prerequisites, step‑by‑step setup, testing, and best practices.

Why VOS3000 Disaster Recovery Matters

VOS3000 stores all critical data – accounts, rates, CDRs – in a MySQL database. If the server crashes, you lose not only current calls but also the ability to route new traffic. A disaster recovery setup provides:

• Automatic failover – slave takes over within seconds
• Data redundancy – real‑time replication prevents data loss
• Minimal manual intervention – no need to reconfigure everything

Understanding VOS3000 High Availability Architecture

VOS3000 uses a master‑slave replication model:

• Master server – handles all live calls, writes CDRs, and accepts configuration changes.
• Slave server – constantly synchronizes data from the master and stands ready to take over.
• Shared virtual IP – clients and gateways connect to a single IP that floats between servers.

When the master fails, the slave detects the outage, activates its softswitch services, and assumes the virtual IP. Calls in progress may drop, but new calls are processed immediately.

Prerequisites for Disaster Recovery Setup

Before you begin, ensure you have:

• Two identical servers with VOS3000 installed (same version, same CentOS/RHEL release).
• Dedicated private network between them for replication (low latency).
• Same MySQL root password on both servers.
• Virtual IP that can be moved between servers (requires `keepalived` or similar).
• Sufficient disk space on both servers (mirroring CDR storage).

Step‑by‑Step VOS3000 Disaster Recovery Configuration

Step 1: Prepare the Master Server

On the master server, enable binary logging and set a unique server ID:

# Edit /etc/my.cnf

[mysqld]

log-bin=mysql-bin server-id=1 binlog-do-db=vos3000db # your actual database name

Restart MySQL and create a replication user:

CREATE USER 'replica'@'slave_ip' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'replica'@'slave_ip';
FLUSH PRIVILEGES;

Record the master status:

SHOW MASTER STATUS;

Step 2: Prepare the Slave Server

Stop MySQL, copy the master data to slave (using `mysqldump` or `xtrabackup`), then configure slave:

[mysqld]
server-id=2
relay-log=relay-log

Start MySQL and set up replication:

CHANGE MASTER TO
  MASTER_HOST='master_ip',
  MASTER_USER='replica',
  MASTER_PASSWORD='strong_password',
  MASTER_LOG_FILE='mysql-bin.xxxxxx',
  MASTER_LOG_POS=xxxx;
START SLAVE;

Verify with SHOW SLAVE STATUS\G – both Slave_IO_Running and Slave_SQL_Running should be “Yes”.

Step 3: Configure Virtual IP with Keepalived

Install and configure keepalived on both servers. Example `/etc/keepalived/keepalived.conf` (master):

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    virtual_ipaddress {
        192.168.1.100/24   # your virtual IP
    }
}

On slave, change state to BACKUP and priority to 100. Restart keepalived.

Step 4: Configure VOS3000 Services for HA

On both servers, ensure that VOS3000 listens on the virtual IP (edit network settings or use IP aliasing). In the VOS3000 web interface, set the “Local IP” of gateways and phones to the virtual IP. This way, after failover, devices reconnect automatically.

Step 5: Test Failover

Simulate a master failure by stopping the master server or the VOS3000 process. Verify that:

• The virtual IP moves to the slave.
• New calls can be established.
• CDRs are written on the slave (and later synced back when master recovers).

Monitoring Disaster Recovery Status

VOS3000 provides built‑in tools to monitor HA status:

• Disaster Tolerance Status – shows current master, slave, and sync lag.
• Disaster Tolerance Data – verify data consistency between servers.
• Disaster Tolerance Equipment – manage registered HA pairs.

Access these via the web interface under “Disaster Recovery System”.

Backup Strategy in a DR Setup

Even with replication, you need regular backups:

• Daily mysqldump of the entire database (compressed, stored off‑server).
• Binary logs – keep them for point‑in‑time recovery.
• Configuration files – backup `/etc` and VOS3000 config directories.

Common Pitfalls and Solutions

• Replication lag – caused by slow network or heavy writes. Monitor with `Seconds_Behind_Master`.
• Split‑brain – both servers think they are master. Use fencing (STONITH) or careful keepalived config.
• Different MySQL versions – always use the same version on both servers.
• Firewall blocking replication port (3306) – open between servers.

Frequently Asked Questions (VOS3000 Disaster Recovery)

Does VOS3000 support active‑active clustering?

No, VOS3000 officially supports active‑passive master‑slave replication. Active‑active is not recommended because of potential conflicts in real‑time billing and CDR sequence.

How long does failover take?

With keepalived and properly tuned services, failover typically completes within 5‑10 seconds. Calls established before failure may drop, but new calls are processed immediately.

Will I lose CDRs during failover?

If replication is synchronous enough, most CDRs are already on the slave. Any CDRs that were in memory but not yet written to the master’s database may be lost. To minimize loss, set `sync_binlog=1` and `innodb_flush_log_at_trx_commit=1` on master.

Can I use a different hardware for slave?

Yes, but it’s recommended to use identical hardware to ensure consistent performance during failover. If the slave is weaker, it may struggle to handle full traffic load.

How do I switch back to the original master after repair?

Repair the master, ensure it has caught up with the slave (re‑sync if needed), then manually promote it back using a controlled switchover procedure to avoid split‑brain.

Conclusion

Implementing VOS3000 disaster recovery with master‑slave replication is the best way to protect your VoIP business from unexpected outages. While the setup requires careful planning, the peace of mind and service continuity are well worth the effort.

Need help configuring high availability for your VOS3000? Contact us on WhatsApp for expert assistance: +8801911119966

Further Resources

• VOS3000 Official Site
• VOS3000 Official Blog
• VOS3000 Downloads
• Multahost Blog
• How to Backup/Restore VOS3000 MySQL Database
• VOS3000 Server Overview