ISPmanager 6 includes a built-in backup module: scheduling, local or remote storage, restoring through the web interface and through the CLI. This section covers a working configuration for VPS and dedicated servers running the panel — from the initial schedule setup to real connection errors with remote storage and verifying that a backup is actually usable for a restore.

Configuring backups in ISPmanager 6

The section is located under Settings → Backups. Here you set the schedule, storage type, and the list of data to copy. The schedule runs through the system scheduler — the job is added to the root user's crontab, so the backup time does not depend on whether the panel happens to be open in a browser.

Parameter	Recommendation
Storage type	FTP or S3-compatible
Schedule	Daily at 3:00
Copies to keep	7 (one week)
Enable compression	Yes (gzip)

What goes into a backup

Site files from user directories
MySQL/PostgreSQL database dumps
Mailboxes and their contents
The panel's own configuration: the list of users, domains, rules

Connecting S3 storage

Remote storage protects against data loss from a hardware failure: the copy physically resides in a different data center. Any provider that supports the standard S3 API works for S3-compatible storage — not only Amazon, but also third-party object storage, as long as it provides an endpoint, access keys, and a bucket.

# Settings → Backups → Add storage
Type: S3
Endpoint: https://s3.yourstorage.com
Access Key: YOUR_KEY
Secret Key: YOUR_SECRET
Bucket: mybackups

Estimating storage volume for backups

Before picking a storage plan, estimate the real volume the copies will take up given rotation. The formula is simple: the size of one full copy multiplied by the number of copies kept, plus a 15-20% margin for data growth between backups.

Component	Typical size	Example for a 3 GB site
Site files	Depends on the media library and uploads	2.5 GB
Database dump (compressed)	10-20% of the DB size on disk	0.4 GB
Mailboxes	Depends on message history	0.1 GB

# Estimate the current data size for the user before setting up storage
du -sh /var/www/user1/data/

Restoring through the CLI

# List the available backups
ls /var/mgr5/backup/

# Restore the site
ispmanager backup.restore --name mysite_20240101.tar.gz

Common errors during backup and restore

Message	What it means
`Error: no space left on device`	The backup volume ran out of space — most often when storing locally on the same disk as the sites
`Connection timed out` when connecting to S3	The endpoint is unreachable, or the server's firewall blocks outbound port 443
`Access Denied`	The Access Key or Secret Key is wrong, or the key lacks write permission on the bucket
`backup.restore: archive not found`	The archive name is wrong, or the file has already been removed after its retention period expired

Incremental vs. full backups

Criterion	Full backup	Incremental
Disk space	More — all data is copied in full	Less — only the changes since the last copy
Creation speed	Slower with a large data volume	Faster after the first full copy
Restore speed	Fast — one archive is enough	Slower — requires a chain of archives
Availability in ISPmanager	A standard panel feature	Requires the separate BackupManager module

When the built-in backup is not enough

You need single-file granularity without unpacking the entire archive — only BackupManager or a manual rsync script with hard-link versioning provides this
Copies must be kept for more than 30 days with deduplication — a growing volume on plain FTP without deduplication quickly becomes expensive and slow to transfer
The database is larger than 20 GB and a mysqldump dump takes hours while locking tables — consider binary replication or mysqldump --single-transaction separately from the regular schedule
You need a near-real-time copy with a minimal RPO (Recovery Point Objective) — a once-a-day schedule cannot provide this; that calls for replication, not a backup

Verifying the restore result

After restoring, confirm that the site and the database actually work, not just that the archive unpacked without errors. The formal "Restore completed" marker in the panel log does not guarantee the application will come up — if an incomplete set of tables or a stale dump was restored, the site can start returning errors at the PHP level.

# Check the last modification date of the site files
stat /var/www/user1/data/www/example.com/www/index.php

# Check that the DB tables are in place and contain data
mysql -u user1 -p -e "SHOW TABLES; SELECT COUNT(*) FROM wp_posts;" mydb

If the site returns a 500 error after the restore, check file ownership: a restore sometimes changes the owner to root, and the web server can't read the files. See also configuring backups in ISPmanager 6 and reading logs when diagnosing failures.