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.
Table of ContentsVOS3000 Disaster Recovery & Backup Setup: Master‑Slave High Availability Important GuideWhy VOS3000 Disaster Recovery MattersUnderstanding VOS3000 High Availability ArchitecturePrerequisites for Disaster Recovery SetupStep‑by‑Step VOS3000 Disaster Recovery ConfigurationStep 1: Prepare the Master ServerStep 2: Prepare the Slave ServerStep 3: Configure Virtual IP with KeepalivedStep 4: Configure VOS3000 Services for HAStep 5: Test FailoverMonitoring Disaster Recovery StatusBackup Strategy in a DR SetupCommon Pitfalls and SolutionsFrequently Asked Questions (VOS3000 Disaster Recovery)Does VOS3000 support active‑active clustering?How long does failover take?Will I lose CDRs during failover?Can I use a different hardware for slave?How do I switch back to the original master after repair?ConclusionFurther Resources
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 STATUSG – 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
VOS3000 Server Rent – Dedicated Best VoIP Servers with Pre-Installed VOS3000 2.1.9.07 for High Concurrent Calls