Backups

Automatic backups are included starting from the mid-range plans, with a frequency that increases on the higher plans. On VPS, they depend on the plan and options. The details are listed per plan on the product pages.

Yes, a premium daily backup option is available to strengthen the protection of your data beyond what your plan includes.

Depending on your plan, you can restore from cPanel. Otherwise, our support team performs the restore at your request.

The retention period depends on your plan and options. Contact support to find out the retention that applies to your plan.

Yes, snapshots are available depending on the VPS plan (VPS Power and VPS Business). They let you freeze the server's state before a sensitive operation.

You have root access: you can automate your backups with tools such as rsync, restic or borgbackup, to a remote storage of your choice.

Combine a Docker volume export with an incremental backup tool such as Restic or BorgBackup. Temporarily stop the container (or use `docker exec` for a clean database dump), compress the volume, then send the archive to remote storage. Schedule the operation via cron or a CI/CD pipeline, and version your `docker-compose.yml` and `.env` files in a private git repository.

Backups included with your hosting plans are stored within the ServOrbit infrastructure. From a VPS, you can configure Restic or BorgBackup to send encrypted off-site copies to S3, Backblaze B2, Scaleway Object Storage, or an SFTP server of your choice. This approach is strongly recommended for any critical data. Ready-to-use templates for these tools are available in the ServOrbit Marketplace.

Yes for MySQL and MariaDB: in the client area (VPS → Manage → Databases) you enable a daily or weekly schedule, pick the hour and the retention period, and the archives are dropped on your backup space. An immediate backup is also available, confirmed with your password and a one-time code — handy right before a sensitive operation such as a major engine upgrade. Other engines (PostgreSQL, MongoDB…) are not detected by this tool: plan your own dump and ship it to remote storage.

Yes, on ServOrbit cPanel hosting plans, JetBackup enables granular restoration: you select the exact file or folder to restore from the available backup list, without affecting the rest of your account. For VPS and dedicated servers, snapshots also offer two levels of recovery — a full disk image restore or browsing the snapshot to extract only the files you need. This flexibility prevents overwriting recent data when you only need to recover a single item.

Restic includes a `restic check` command that scans the repository and detects any corruption in the encrypted blocks, without restoring data. Schedule this check via a systemd timer or a weekly cron job, and pipe the output to an alert channel (email, n8n webhook, ntfy). If the command returns a non-zero exit code, a test restore to a temporary directory quickly confirms whether your data is actually recoverable before an incident occurs.

In cPanel, JetBackup lets you restore to a different destination folder rather than overwriting the original location. Choose the 'Restore to' option and specify a temporary directory; you can then compare the restored files with production files before any cut-over. This method keeps your site available throughout the verification. If you need assistance, open a ticket from your client space.

A VPS snapshot is an instant image of your entire server disk, ideal before a risky operation; it is stored on the same infrastructure and can be restored quickly. JetBackup (available on cPanel hosting) provides automatic incremental backups of your files, databases and emails, stored on a remote space, with file-by-file restoration from cPanel. For comprehensive VPS protection, combine snapshots with an external backup solution (Restic, BorgBackup).

Several approaches exist depending on the level of granularity required. The most direct method is to use `docker run --rm -v <volume>:/data alpine tar czf - /data` to archive a volume into a file, then transfer that file to external storage via `rsync` or `rclone` (compatible with S3, SFTP, and more). For consistent database backups, prefer an application-level dump (`pg_dump`, `mysqldump`) over a raw volume copy. Automate these backups with a daily cron job and retain multiple generations. ServOrbit also offers schedulable VPS snapshots from the client area, which can serve as an additional safety net.

Yes, it is entirely possible to restore a backup from one VPS to another — for example to migrate to a more powerful plan or to create a disaster recovery environment. **With JetBackup** (optional licence at 119 DH/month, on a server running cPanel): connect to the JetBackup interface, select the backup to restore, and choose **Restore to another server**. Enter the destination VPS IP address and SSH credentials. JetBackup automatically transfers and restores the data. **Without JetBackup**: export your backup (snapshot or tar archive) from the client area, download it to the destination VPS via `rsync` or `scp`, then restore manually. Note that IP addresses change during a migration: remember to update your DNS and application configurations after the restore.

Docker volumes are where your Docker applications store their persistent data (databases, uploaded files, configurations). Here are three approaches to back them up. **Approach 1 — Direct volume directory backup**: Docker volumes are stored in `/var/lib/docker/volumes/`. Each volume is a named directory you can back up directly with tar: `tar czf /backup/myvolume-$(date +%Y%m%d).tar.gz -C /var/lib/docker/volumes/myvolume/_data .` **Approach 2 — Export via temporary container** (recommended): works without knowing the physical volume path: `docker run --rm -v myvolume:/data -v /backup:/backup alpine tar czf /backup/myvolume-$(date +%Y%m%d).tar.gz -C /data .` **Approach 3 — Application snapshot** (for databases): use the database's native tool to export a consistent dump before backing up. For example, PostgreSQL in a container: `docker compose exec -T db pg_dump -U user my_db | gzip > /backup/db-$(date +%Y%m%d).sql.gz` To automate, add the command to a script and schedule it with cron. Then sync to remote storage with rclone for off-site protection.

Yes: before any major update to a self-hosted application (CMS, financial tool, mail server…), take a full backup of both files and the database — even if your VPS already benefits from scheduled automatic backups. A snapshot taken just before the update lets you roll back to a known stable state within minutes if an incompatibility arises. The frequency of included automatic backups varies by your ServOrbit plan; see /tarifs for per-plan details.

A bare clone (`git clone --bare <url>`) copies the full history, branches and tags with no working tree, making it the ideal format for archiving and restoring. From your VPS, schedule a cron job that runs `git clone --mirror` into a backup directory, then compress and transfer the archive to external storage (S3, SFTP). For more details, see our self-hosted Gitea guide at `/vps-cloud`.

Before any update, archive the `/etc/postfix/` directory (main configuration), `/etc/opendkim/` or `/etc/dkim/` (DKIM keys) and the `/etc/aliases` file. Use `tar -czf postfix-backup-$(date +%F).tar.gz /etc/postfix /etc/opendkim` then transfer the archive off-server with `rsync` or `scp`. Also keep a copy of the matching DNS TXT records so you can republish the keys if needed. Contact our support at [email protected] for restore assistance.

For PrivateGPT, back up the `local_data/` folder (indexed documents and vector database) along with the `settings.yaml` configuration file. For LocalAI, archive the models directory (usually `models/`) and any YAML profile configuration files. Schedule an `rsync` task or use Restic to transfer these folders to external storage; model files can be large, so consider deduplication. Find our PrivateGPT and LocalAI templates on the ServOrbit Marketplace at `/vps-cloud`.

First stop the Mattermost container (`docker compose stop mattermost`) to avoid any in-flight writes, then run a dump: `docker exec mattermost-db pg_dump -U mmuser mattermost | gzip > mattermost-backup-$(date +%Y%m%d).sql.gz`. Store the archive off the VPS (object storage, `scp`/`rsync` transfer) before starting the upgrade. To restore: `gunzip -c mattermost-backup-YYYYMMDD.sql.gz | docker exec -i mattermost-db psql -U mmuser mattermost`. The ServOrbit backup option takes a full disk snapshot — enable it as well to also cover file volumes.

By default, Chatwoot stores uploaded files in the container's `storage/` folder — these are lost if the container is recreated. Cloudflare R2 is S3-compatible with no egress fees. Important: an incompatibility between Active Storage (Rails) and R2 silently drops attachments (issue chatwoot#13299). The fix is to add `request_checksum_calculation: "when_required"` and `response_checksum_validation: "when_required"` to the R2 service block in `config/storage.yml`. Both parameters must be set together. Then configure `ACTIVE_STORAGE_SERVICE=amazon`, `S3_BUCKET_NAME`, `S3_REGION`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` and `S3_ENDPOINT` in your `.env` file. Restart the containers and test by uploading a file in a ticket.

Docmost stores its data in a PostgreSQL database and its files (images, attachments) in a Docker volume or S3-compatible object storage. For a complete backup before any migration or major upgrade: (1) run `pg_dump -U docmost docmost > docmost_backup_$(date +%Y%m%d).sql`, (2) archive the Docker file storage volume or export your R2/S3 bucket, (3) schedule this backup in a cron script on your VPS and send the archives to external storage (S3, Backblaze B2 or SFTP) to avoid keeping backup and data on the same disk.

Stalwart stores its data in a configurable directory (default `/opt/stalwart-mail/data`): stop the service, copy that folder to remote storage with Restic or BorgBackup, then restart. Make sure to include TLS certificates (Let's Encrypt or custom), DKIM keys (under the `dkim/` subdirectory), and the `config.toml` configuration file. For Docker installations, mount the data directory as a named volume and back up that volume. Schedule daily backups via cron and periodically verify restoration on a test VPS.

Backup frequency should be proportional to your **RTO (Recovery Time Objective)** and **RPO (Recovery Point Objective)** — how long you can afford to be down, and how much data you can afford to lose. **Practical recommendations:** | Site type | Frequency | Retention | |---|---|---| | Static showcase | 1×/week | 4 weeks | | Active blog | 1×/day | 30 days | | E-commerce | 4×/day | 30 days + 3 monthly | | Critical application | 1×/hour | 48h hourly + 30d daily | **Where to store backups — 3-2-1 rule:** - **3** copies of data - On **2** different media - With **1** offsite In practice: snapshot on the same VPS (fast to restore) + copy to an S3 bucket or another VPS (protects against primary server failure). **What ServOrbit offers:** automatic daily snapshots included in VPS plans, with configurable retention. Data stays in Europe.

Before any sensitive operation on Plane, back up the application's Docker volumes. The command `docker compose exec plane-db pg_dump -U plane plane > plane_backup.sql` exports the main database; complement this with a copy of configuration files (`.env`, `docker-compose.yml`) and any uploads stored on disk. Test the restore on a staging environment before proceeding with the migration.

Yes, it is essential: a major PostgreSQL version upgrade (e.g. 15 → 17) changes the internal data format and cannot be reversed without a restore. Before any migration, export a full dump with `pg_dumpall -U postgres > backup_before_migration.sql` and keep it on storage separate from your VPS (Backblaze B2, a remote SFTP). Verify the restore works in a test environment before shutting down the old engine. If you use ServOrbit's premium backup option, confirm the latest snapshot is recent before starting the procedure.

Elasticsearch provides a Snapshot and Restore API that creates deduplicated incremental backups of your indices. Configure an S3 repository (compatible with Backblaze B2, Cloudflare R2, or any S3-compatible object storage) and define a Snapshot Lifecycle Policy (SLM) to automate frequency and retention. Important: never copy data files directly from disk while Elasticsearch is running — only the native snapshot mechanism guarantees a consistent backup. Regularly test a restore on a second VPS to validate integrity.

For a production VPS, aim for at least one daily backup with a 7-day retention period. Critical applications (databases, client files) warrant hourly or incremental backups. Distinguish between system snapshots (useful before an update) and data backups (essential for continuity). Regularly test restoration: a backup whose restore has never been verified is an unreliable backup. Store copies on a remote site or an object storage service independent of your VPS.

A snapshot is a point-in-time image of the disk state, taken at the hypervisor level: quick to create, it lets you roll back in minutes, but remains tied to the same physical storage. A full backup copies the data to a separate location (another server, object storage) and protects against hardware failure. Both are complementary: snapshots cover human errors and failed updates, backups cover disasters and data loss. On a ServOrbit VPS, snapshots and automatic backups are available depending on the plan.

ERPNext generates compressed backups via `bench backup` in the `private/backups/` folder of each site. Combine this with `rclone` or the AWS CLI to push each archive to an S3-compatible bucket (Backblaze B2, Cloudflare R2, MinIO…) right after it is created. Schedule everything with a nightly cron job, encrypt archives client-side before upload if they contain sensitive data, and regularly test restoration in a test environment to validate their integrity. Keep at least 7 daily and 4 weekly copies.

Log in to your ServOrbit client area, open a support ticket in the "Hosting" category, and specify the backup date you need as well as the path or database to restore. Our team will perform the restoration from JetBackup snapshots as quickly as possible. If you have the JetBackup option, you can also trigger the restoration yourself directly from the cPanel interface without contacting support.

A snapshot is an instant disk copy taken at the hypervisor level: ideal for rolling back after a mistake, but it lives on the same physical infrastructure as your server. The 3-2-1 rule goes further: 3 copies of your data, on 2 different media, with 1 offsite. If the data centre is affected by a hardware failure, flood, or accidental account deletion, only the offsite copy protects you. Combine snapshots (speed) with an offsite backup to an external object store (Backblaze B2, S3, Scaleway…) to cover both risk levels.

Yes, that is precisely the advantage of a Restic repository hosted outside your VPS. The repository lives on the external object storage (S3, Backblaze B2, Scaleway…) and has no dependency on your server: you can access it from any machine that has the Restic binary, the encryption key, and the repository credentials. Store these in a secrets manager (Bitwarden, Vault…) that is independent of your infrastructure, and test a restore on a third-party machine at least once a month.