Disaster Recovery¶

enconf can be fully restored in minutes after a complete system failure — onto a fresh, empty server. The only prerequisite: you must have created at least one Panel backup in advance and stored the encryption key externally.

What disaster recovery restores¶

A panel backup contains everything required for a complete restore:

Area	Contents
Panel database	All customers, subscriptions, sites, DNS zones, mail accounts, permissions, webhooks, license status, encrypted secrets
Full MariaDB	All databases including customer DBs, with users, grants, stored procedures, triggers, events
PowerDNS backend	All DNS zones and records (auto-detected: MySQL/PostgreSQL/SQLite)
Roundcube	Identities, contacts, sieve filters
Configuration	Nginx, PHP-FPM (all versions), Postfix, Dovecot, ProFTPD, Cron, Let's Encrypt, fail2ban, nftables, ModSecurity, Unbound, rspamd
Linux users	Account data with UID/GID and password hashes — customer FTP/SFTP logins keep working without password reset
rspamd Bayes	Trained spam statistics are preserved
fail2ban runtime	Active bans are preserved
Network identity	Hostname, /etc/hosts, /etc/resolv.conf, Netplan

Preparation (now, before anything happens)¶

In the admin panel, go to Backups
Click New schedule
Choose Backup type: Panel backup
Configure frequency, retention and target (S3, FTP or local)
Click Create
Click the key icon in the schedule table
Click Download as file — store the file externally (password manager, USB drive, safe)
For external targets, also note the S3/FTP credentials

No encryption key, no recovery

The encryption key is the only way to read the backup. Without it the backup is unusable. Store it in a location that is not on the same server.

Recovery in case of disaster¶

Prerequisites¶

Fresh Debian 12/13 or Ubuntu 24.04 server (same major version as the original, same or newer PostgreSQL version)
At least as much disk space as the original system
Backup target credentials (S3 endpoint, bucket, access key, secret key — or FTP host/user/password)
Encryption key from your earlier external backup

Steps¶

Install enconf on the fresh server:

apt update
apt install netcell-webpanel

Open the setup wizard in the browser at https://<server>:3443
The first screen shows two cards — choose Disaster Recovery
Enter the backup source:
Source: S3, FTP or Local
Connection details
Encryption key (from your previously saved file)
Connect and load snapshots — the wizard lists all available panel snapshots
Choose a snapshot — the latest is selected by default
Review the preview — the wizard shows hostname, IP, customer count, database count and detected services from the backup
Type RESTORE to confirm and click Start restore
The restore runs in 10 steps (live progress + log):
Verify target system is empty
Extract snapshot
Validate metadata
Stop services
Recreate linux users (with password hashes)
Apply configurations
Restore PostgreSQL
Restore MariaDB
Start services
Finalize
Log in with your old admin password — the panel is back
Phase B: After login, a yellow banner appears at the top: "Disaster Recovery — Phase B pending". Click Restore customer data to open a modal listing all customer backup schedules. Restore all sequentially restores web roots, maildirs, SSL certificates and customer databases from the customer backups. Individual failed schedules can be retried separately.

After recovery¶

Item	Description
Reactivate license	Licenses are hardware-bound. After a hardware change, deactivate the old activation in the NetCell Licensing portal and reactivate.
Hostname	If the new server has a different hostname, Postfix/Dovecot may need manual updating.
IP address	If the IP changed, DNS A records still point to the old IP — update them in DNS management as needed.
Customer data	Web files, mailboxes and SSL certificates are restored from the customer backup — restorable from the backup management UI after a successful panel restore.

Multi-server setups¶

enconf can run in multi-server topologies where Web, DB, Mail and DNS services live on separate servers. For these setups there is an additional backup type: Node backup.

Concept¶

Backup type	Where it runs	What it backs up
Panel backup	Panel host	PG panel DB + configs/state of all roles that live on the panel host
Node backup (new)	Any remote server	Only the role-specific configs and stateful data of that one server

You create one node backup schedule per server in your cluster. The agent on the target server detects from SERVER_ROLES which configs to back up — a web node only tarballs nginx/php/proftpd, a DNS node only PowerDNS/Unbound, etc.

Setup¶

Backups → New schedule
Backup type: Node backup
Select the target server from the list
Configure frequency, retention, target (S3/FTP/local), save the encryption key externally
Repeat for each server in your cluster

Schedules land in separate repository segments: - <bucket>/<path>/_panel — panel backup - <bucket>/<path>/_node_2 — node backup for server ID 2 - <bucket>/<path>/_node_3 — node backup for server ID 3 - <bucket>/<path>/server — customer data (server-wide)

Multi-server recovery flow¶

Phase A — Restore the panel host as in the single-server flow above.

Phase B — Restore each remote server

For each remote server (web/db/mail/dns) from the original setup:

Provision a fresh server
apt install netcell-agent
In the panel: Servers → Add server — register the new server with the same server ID as before (so the _node_<id> repo segment matches)
Open the node backup schedule for that server → Restore → pick a snapshot
The agent on the new server receives the restore-node instruction with node_server_id, pulls everything from the _node_<id> segment and applies it

Phase C — Distribute customer data

The customer backup is server-wide and contains web roots, maildirs and SSL certs for all customers. After login it is restored through the regular backup management UI — agentForSchedule automatically routes each customer to its originally assigned server (based on Site.ServerID from the restored panel DB).

Node backup content per role¶

Role	In the node backup
`web`	Nginx, PHP-FPM (all versions), ModSecurity, fail2ban, ProFTPD, linux users with hashes
`mail_storage`	Dovecot configs + lib (auth cache, indexes), Let's Encrypt mail certs
`mail_gateway`	Postfix configs, rspamd configs + Bayes DB
`dns`	PowerDNS configs + lib, Unbound configs + DNSSEC trust anchor
(all roles)	Cron tabs, hostname/network identity, agent token

Known limitations¶

PostgreSQL major version: restore works on the same or newer PG major version. A downgrade (e.g. PG17 → PG14) is not supported.
OS family: only tested between Debian/Ubuntu versions with the same service layout conventions.
Hostname change: Postfix/Dovecot configs contain the original hostname — manual adjustment recommended.
MariaDB major upgrade: with auth-plugin changes (10.x → 11.x), individual user grants may need adjusting.