Backups

Automatic backups are included starting from the mid-range hosting plans, with a frequency that increases on the higher plans. On VPS, nothing is automatic: snapshots and backups are started on demand from your client area, depending on the plan and the Backup storage option. The details are listed per plan on the product pages.

No, there is no premium daily backup option. On shared hosting, daily backup is included in the Pro plan; the Business plan includes a weekly backup.

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, JetBackup allows granular restoration: you select exactly the file or folder to restore from the list of available backups, without touching the rest of your account. On a VPS, however, restoring a snapshot applies to the whole snapshot: it replaces the server's current state, with no file-by-file extraction. Dedicated servers have neither snapshots nor backups provided: restoring a file relies on your own backups. On cPanel, this granularity avoids overwriting recent data when recovering 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 on-demand 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 95 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 you already schedule your own backups. A snapshot taken just before the update lets you roll back to a known stable state within minutes if an incompatibility arises. On a ServOrbit VPS, no backup is scheduled automatically: create a snapshot from your client area just before the update; the snapshots and backups included in each plan are detailed on /tarifs.

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:** VPS snapshots created on demand from the client area (from the VPS Power plan up) and backup storage on separate storage (VPS Business or as an option). Nothing is scheduled automatically: the frequency and retention above are automated on your side (cron, Restic, Borg). 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-version PostgreSQL upgrade (e.g. 15 → 17) changes the internal data format and cannot be undone without a restore. Before any migration, export a full dump with `pg_dumpall -U postgres > backup_avant_migration.sql` and keep it on storage separate from your VPS (Backblaze B2, remote SFTP). Check that the restore works on a test environment before switching off the old engine. If you use your ServOrbit VPS snapshots, confirm that 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 backups are available depending on the plan and are started on demand from your client area.

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.

On shared hosting, restoration is self-service: from your ServOrbit client area, open cPanel (“Access cPanel”), then the JetBackup menu; choose the backup for the date you need and the item to restore (full account, files, database). The backups available depend on your plan: weekly on Business, daily on Pro; Start does not include backups. If you run into difficulty, open a support ticket in the "Hosting" category, specifying the backup date and the path or database to restore.

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.

In cPanel, open JetBackup, choose 'File Backups' and browse to the file in the list of available backups. Select the desired date, then click 'Restore' next to the file to restore it alone without affecting the rest of the account. If you cannot find the file, contact [email protected] with the path and target date.

On shared hosting, the frequency depends on the plan: Start includes no backup, Business includes a weekly backup and Pro a daily backup. VPS plans have configurable policies depending on your contract; dedicated servers, for their part, come with no backup provided. Check your client portal or write to [email protected] to learn the exact policy for your plan.

Before any major PostgreSQL migration, take a full dump using `pg_dumpall -U postgres > backup_before_migration.sql` for the whole cluster, or `pg_dump -U postgres -Fc db_name > db_name.dump` for a single database (compressed format, restorable with `pg_restore`). Verify the dump is complete and readable before launching the upgrade. To restore, create a fresh cluster with the new version and then import using `psql` or `pg_restore`. See our article on PostgreSQL 18 migration for version-specific precautions.

For a production Odoo instance, a daily full backup of the PostgreSQL database is the recommended minimum. Businesses with high transaction volumes or a low tolerance for data loss prefer incremental backups every 4 to 6 hours. Files in the `filestore` directory (attachments, documents) must be backed up at the same frequency as the database to ensure consistency. It is also advisable to retain at least 7 days of daily backups and 4 weeks of weekly backups, stored in a remote location or object storage separate from the main VPS.

Before any move, verify that your latest full backup (files, databases, emails) is recent and tested. On our hosting plans, you can trigger a manual backup from cPanel at any time. On a VPS, take a snapshot if your plan allows it, or export your volumes before the migration. Keep the old infrastructure active until the new site is validated and DNS propagation is complete — the switchover window is thus reversible without data loss.

ServOrbit does not schedule any automatic backup of your VPS: snapshots and backups are started on demand from your client area, depending on your plan — snapshots from the VPS Power plan up, backups with the backup storage included on VPS Business or as an option. Restoring a snapshot or a backup is available as self-service from your client area in a few clicks. For enhanced protection, it is recommended to combine these tools with an external application backup scheduled on your side (e.g. Borg Backup or Restic to object storage). Snapshots live on the same storage as the VPS; only backups are kept on separate storage, to withstand hardware failure.

The recommended method is to use a cron script that runs `docker run --rm -v <volume>:/data -v /backup:/backup alpine tar czf /backup/<volume>-$(date +%F).tar.gz /data`, then transfers the archive to remote storage (S3, SFTP). Tools like Restic or Duplicati can automate this cycle with encryption and configurable retention. Regularly verify your restores: an untested backup is not a backup. You can open a support ticket to get recommendations tailored to your stack.

The time a restoration takes depends on the data volume and the type of backup used: a JetBackup restoration of a light cPanel account (a few hundred MB) generally takes less than 30 minutes from the client area, on a self-service basis. For larger accounts or partial restorations (a single file, a single database), the time is similar. In the event of a major disaster requiring intervention by our team, open an urgent-priority ticket from your client area describing the impact; our team handles the request within the timeframes of our SLA (99.9% availability). To minimise the risk of data loss, choose a plan whose backup frequency suits you: Business includes a weekly backup, Pro a daily backup.

Yes, your ServOrbit VPS gives you full root access: you can install rclone or Restic and set up automatic backups to any S3-compatible object storage (AWS S3, Backblaze B2, Wasabi…). It is recommended to schedule backups via a systemd timer or crontab, encrypt archives (Restic encrypts natively), and regularly test a full restore. On shared hosting, backups run through JetBackup, built into cPanel: the backups included depend on the plan (weekly on Business, daily on Pro, none on Start), and you restore them yourself from the JetBackup menu in cPanel.

In the Backrest interface, use the Restore function by selecting a recent snapshot and a temporary target (e.g., `/tmp/restore-test`). Then verify that key files are present and readable. Schedule this test monthly by adding an automated task in Backrest or a dedicated cron — an untested backup does not replace a real recovery policy.

Yes, Backrest allows you to define multiple repositories in its configuration, each pointing to a different backend (S3, Backblaze B2, SFTP, local…). You can thus replicate your backups to two distinct S3 buckets or combine local and remote object storage. Each repository has its own schedule and retention policy.

No: ServOrbit dedicated servers include neither automatic backups nor snapshots — the physical server does not offer these functions, and the backup strategy is up to you (regular copies to independent external storage). In the event of a disaster, restoration is done from your own backups; if the system needs to be reinstalled, the request is made to the support team, and the reinstallation wipes the disk. For any question about the strategy to put in place, contact [email protected].

Infisical encrypts its secrets in the database using a master encryption key (`ENCRYPTION_KEY`) that is separate from the PostgreSQL data. Best practice is to back up the PostgreSQL database (encrypted dump with Restic or pg_dump + gpg) and store the `ENCRYPTION_KEY` separately — in an offline secrets manager or external vault — never in the same archive or on the same server. This way, even if the database backup is compromised, the secrets remain unreadable without the key. Regularly test a full restore (database + key) in an isolated environment.

Connect to your VPS via SSH and run `mysqldump -u root -p your_database_name > backup.sql` to export a database to a readable SQL file. To automate this backup, add the command to a cron job (`crontab -e`) and transfer the file to remote storage (SFTP, S3 or Backblaze B2) using `rsync` or `rclone`. ServOrbit also offers on-demand VPS snapshots from your client area, complementing application-level backups.

The recommended approach is to run `pg_dump` via a systemd timer or cron job, then send the encrypted archive to remote storage (S3-compatible, SFTP) using a tool such as Restic or Rclone. A minimal cycle: daily backups kept for 7 days and weekly backups kept for 4 weeks. Regularly test restoration to a temporary directory — an untested archive is not a backup. Our support team can guide you from your client area.

Before the upgrade, take a snapshot if your plan allows it (VPS Power and VPS Business), then a backup of the panel (accounts, sites, databases, mailboxes) copied OFF the server: a snapshot is stored on the same infrastructure. Also keep a copy of the panel configuration and your scheduled tasks. Test restoring one site before starting, and if the upgrade fails, reinstalling the OS from your client area wipes the disk: without that external copy, there is nothing to put back.

Restore it somewhere other than your production server: in a temporary directory or on a second, disposable VPS. Check that the key files open, that the database starts again with its data and that the application responds, then note how long the whole thing took. Repeat this test at regular intervals and after every significant change to your setup: only a successful restore proves the backup is of any use.

Restoring a snapshot replaces the entire state of the server: anything written after it was created (orders, form submissions, uploaded files) is gone. Before restoring, copy that data off the VPS, for example a database export and an archive of the folders that changed, and take a new snapshot if your plan includes them (VPS Power and VPS Business) so you can roll back. Then restore, re-import the recent data and check the site before reopening it to the public.

A clean backup brings the site back clean, but it also restores the flaw that allowed the intrusion: without a fix, the hack can happen again. After restoring, update the core, plugins and themes, remove those you no longer use, then change every password (administrators, database, FTP and SSH access) and the security keys. Choose a backup dated before the first trace of compromise, not simply the most recent one, and keep a copy of the infected state for analysis.