# Volume Backups

URL: /docs/backups/volumes

Source: https://github.com/easypanel-io/monorepo/blob/main/apps/website/content/docs/backups/volumes.mdx

Mirror App and Box volume mounts to a storage provider.



Easypanel can schedule backups of named volume mounts attached to App and Box
services. Volume backups protect persistent application data such as uploads,
generated assets, and user-managed files.

Only **Volume** mounts are available. **Bind** and **File** mounts are not
included and need a separate recovery plan.

## How volume backups work [#how-volume-backups-work]

Every run uses `rclone sync` to make the configured destination path match the
selected volume.

<Callout type="warn">
  A volume backup is a mirror, not a timestamped snapshot. A later run updates
  changed files and can delete destination files that no longer exist in the
  source volume. Easypanel does not provide per-run retention or a restore
  action for volume backups.
</Callout>

Use provider-side versioning, snapshots, or lifecycle rules when you need to
recover older versions or deleted files. Give every volume its own destination
path so one sync cannot affect another volume's data.

## Create a volume backup [#create-a-volume-backup]

1. Add a **Volume** mount to an App service's **Storage** tab or a Box service's
   **Mounts** section.
2. Deploy or rebuild the service so that the mount is active.
3. Configure a destination under the server's
   [**Settings → Storage Providers**](/docs/storage-providers).
4. Return to the service's storage or mounts section and open **Volume
   Backups**.
5. Create a backup configuration.
6. Select the volume, enable the configuration, and choose a schedule preset or
   enter a cron expression.
7. Select the storage provider and enter a unique destination path.
8. Save the configuration.
9. Open its actions menu, select **Manual Run**, and review **Volume Backups
   Logs**.
10. Confirm the expected files at the destination.

The default schedule is daily at `02:00`:

```text
0 2 * * *
```

Cron schedules follow the server's time. Schedule large volumes outside peak
traffic and leave enough network bandwidth and destination capacity for the
sync.

## Consistency [#consistency]

Files can change while a volume sync is running. For data that requires a
consistent point in time, stop writes or put the application in maintenance
mode before a manual run.

Do not use a volume copy of a live database data directory as a substitute for
a database dump. Database engines may have in-memory or partially written state
that makes copied files unusable. Use [Database Backups](/docs/backups/database)
for MySQL, MariaDB, PostgreSQL, and MongoDB.

For a WordPress site, protect both:

* its MySQL or MariaDB database with a database backup;
* uploads and other persistent files with a volume backup or a provider that
  already stores them externally.

## Restore volume data [#restore-volume-data]

Easypanel does not currently restore a volume from the interface. Recovery is a
manual operation:

1. Identify the correct service, volume, destination, and recovery point.
2. Stop the service or otherwise prevent writes to the target volume.
3. Take a safety copy of its current contents.
4. Copy the backup data from the storage provider into the intended volume,
   preserving the directory structure and required ownership.
5. Start the service.
6. Verify expected files, permissions, application behavior, and a
   representative write.

The exact restore method depends on the storage provider and server access. Test
it with non-production data before treating the scheduled mirror as
recoverable.

## Edit or remove a configuration [#edit-or-remove-a-configuration]

Editing the provider or destination path makes future runs sync to the new
location. It does not move data from the previous destination.

Removing a configuration stops its schedule and removes it from Easypanel. It
does not delete the remote mirror.

## Troubleshooting [#troubleshooting]

When a volume run fails:

1. Open its entry under **Volume Backups Logs**.
2. Confirm that the selected volume still exists on the service.
3. Confirm that the [storage provider](/docs/storage-providers) still exists
   and is connected.
4. Check provider permissions, destination capacity, and network access.
5. Verify the enabled state, cron expression, and server timezone when a
   schedule does not start.
6. Run the configuration manually after correcting it.

If a bind mount contains important data, back up its host path with a separate
server-level tool. A bind mount will not appear in the volume selector.