ISPmanager 6 has a built-in backup system. You can configure daily automatic backups of sites, databases, and mail, stored on local disk, FTP, or S3.

Configuring the Backup Schedule

Tools → Backup → Schedule → Create.

Parameter	Description
Period	Daily / Weekly / Monthly
Time	02:00–04:00 at night is recommended
What to include	Files, DB, mail, configs
Copies to keep	7 (a week) or 14 (two weeks)

Pick the backup time based on the site's lowest-traffic window rather than arbitrarily: if nighttime traffic is still significant (for example, an audience in other time zones), copying large databases in full can noticeably slow the site down during exactly that window.

What is not included in a backup by default

OS-level system settings outside the site directories (for example, custom Nginx configs edited manually outside the panel)
Cron jobs added directly via crontab -e, bypassing the ISPmanager interface
Data from third-party services running separately from the panel (Docker containers, separate databases outside the panel's MySQL/PostgreSQL)

Configuring Remote Storage

FTP Server

Tools → Storage → Add → FTP. Specify the IP/host, login, password, and folder.

Amazon S3 / Compatible Storage

Tools → Storage → Add → S3. Specify the endpoint, access key, secret key, and bucket.

✅ Store backups on a separate server or S3. A backup on the same disk won't protect you from an HDD failure or a hack.

Creating a Backup Manually

Tools → Backup → Create. Select the users and data to back up.

Restoring from a Backup

Tools → Backup → select the archive → Restore.

Restore everything — full restoration
Selective — choose specific files or a DB

⚠️ Restoring from a backup overwrites the current data. If you need to preserve the current state, make a manual backup first.

Checking Your Backups

Regularly check that backups work — run a test restore once a month. A backup that can't be restored isn't a backup.

Common backup errors explained

Message / symptom	What it means
The backup job stays stuck "In progress" for hours	Usually means a network problem reaching remote storage, or the database locking a file during the dump
`mysqldump: Got error: 1044: Access denied`	The MySQL user the backup runs as doesn't have enough privileges on the specific database
The backup archive's size grows by tens of percent every time	Temporary files or logs that grow without rotation are accidentally included — exclude them from the list of copied directories
A backup notification arrives, but the archive isn't in storage	The notification fires when the job finishes, not when the write to storage succeeds — check both events separately

Local, FTP, and S3 storage compared

Criterion	Local disk	FTP	S3-compatible
Protection from server failure	No	Yes	Yes
Write speed	High	Depends on the link	Depends on the link and region
Cost	Included in the VPS plan	Usually lower than S3	Charged for volume and requests
Version rotation convenience	Manual	Manual or via the panel's schedule	Often has built-in bucket versioning

When the built-in schedule isn't enough

You need a backup before every release rather than on a fixed schedule — it's more convenient to trigger a manual backup from a CI/CD pipeline via the API instead of relying only on the panel
You need simultaneous storage in several geographically separated locations (a 3-2-1 strategy) — ISPmanager's standard schedule targets one storage location per job, so multiple copies require separate jobs or a script built on top of the API
The data volume is so large that a full backup no longer fits in the nightly window — you need an incremental scheme or replication instead of periodic snapshots

Verifying the result

A backup job finishing without errors is not proof that the data is actually restorable. Once a month, run a test restore on a separate test server or container.

# List the available archives and their size
ls -lh /var/mgr5/backup/

# Unpack the archive into a temporary directory to inspect its contents
tar -tzf mysite_20240101.tar.gz | head -20

If the archive opens but doesn't contain the expected files, or the database dump is empty, the backup job only "succeeded" formally while the real data never made it into the copy. It's worth automating this check with a separate script rather than relying on memory. Related topics: configuring backups and restoring and working with databases in ISPmanager 6.