1. Why Backups Are Critical#

When self‑hosting applications on a VPS with Dokploy, having a reliable backup strategy is not just important—it’s essential.
Whether you’re running production apps, databases, or personal projects, data loss can be devastating.

2. Why Choose Cloudflare R2?#

Even after yesterday’s epic outage, it’s still our only choice—everything else is simply too expensive.

Cloudflare R2 is a high‑performance, low‑cost object storage solution, especially suitable for reliable backup scenarios. Key features include:

• High availability: R2 uses multiple data centers worldwide to ensure no single failure can destroy your data.
• Low cost: compared to traditional cloud storage, R2 offers more competitive pricing.
• Flexibility: R2 supports multiple access methods, including HTTP/HTTPS, API, and CDN acceleration.
• 10GB storage – free forever, ideal for small to medium deployments
• Zero egress fees – unlike AWS S3, you don’t pay to download data.
• S3‑compatible – works with any S3‑compatible tool or application
• Global distribution – data is automatically distributed across Cloudflare’s network
• No hidden fees – transparent pricing with no surprises

3. Create a Cloudflare R2 Bucket and Connect It to Dokploy#

Step 1: Configure a Cloudflare R2 Bucket#

1
- Length 3–63 characters
2
- Lowercase letters, numbers, and hyphens only
3
- Must start and end with a letter or number
4
- No spaces or special characters

1
Access Key ID: f3811c6d27415a9s6cv943b6743ad784
2
Secret Access Key: aa55ee40b4049e93b7252bf698408cc22a3c2856d2530s7c1cb7670e318f15e58

1
https://2391372198321037123xdwewqe.r2.cloudflarestorage.com

Step 2: Configure an S3 Destination (Cloudflare R2) in Dokploy#

1
WNAM – Western North America
2
ENAM – Eastern North America
3
WEUR – Western Europe
4
APAC – Asia‑Pacific

1
https://xxxxxxxxxxxxxxxxxxxx.r2.cloudflarestorage.com

4. Backing Up the Dokploy System#

Dokploy provides a comprehensive backup system.

1. Dokploy system backups
   These backups include your entire Dokploy installation:

Contents:

• PostgreSQL database (dokploy-postgres) with all app configuration

• Dokploy filesystem (/etc/dokploy) with settings, certificates, and metadata

• Application definitions, environment variables, and deployment history

• Traefik configuration and SSL certificates

• When to use:

• Before major Dokploy upgrades or migrations

• After significant configuration changes

• Disaster recovery scenarios

• Migrating to a new server

• Recommended schedule: daily automatic backups with 7 days of retention.

2. Database backups
   Separate database backups for your applications:

Supported databases:

• PostgreSQL (via pg_dump)
• MySQL (via mysqldump)
• MariaDB (via mariadb-dump)
• MongoDB (via mongodump)

Contents:

• Full database schema (tables, indexes, constraints)
• All data in compressed format
• User privileges and roles
• Stored procedures and functions

When to use:

• Before app upgrades or schema migrations
• For point‑in‑time recovery
• When testing major data changes
• To create dev/test environments
• Recommended frequency: production DB every 6 hours; development DB daily.

3. Volume backups
   Docker volume backups for applications that use file‑based storage:

Ideal for:

• SQLite databases (e.g. n8n, Memos)
• File uploads and user‑generated content
• Config files stored in volumes
• Apps without a traditional database

Contents:

• Full volume contents
• File permissions and ownership
• Directory structure

When to use:

• Apps using SQLite or embedded databases
• Services storing important files in volumes
• Content management systems
• Before container updates
• Suggested schedule: high‑churn content daily, static content weekly

Step 3: Back Up the Dokploy System#

Dokploy system backups are the most critical ones—they include all application configuration, environment variables, deployment records, and system metadata.

1
Web Servers → Backups

1
minute hour day month weekday

1
0 2 * * *      # Every day at 2 AM
2
0 */6 * * *    # Every 6 hours
3
0 2 * * 0      # Every Sunday at 2 AM
4
0 3 1 * *      # First day of every month at 3 AM
5
*/30 * * * *   # Every 30 minutes

3.4 Run a manual backup test (strongly recommended)#

Before relying on scheduled backups, you should validate them once:

1. Click Run backup now or Test backup
2. Wait about 1–3 minutes
3. Open the Cloudflare R2 bucket and verify that files have been uploaded
4. Download a backup and confirm it can be extracted without corruption

5. Backing Up Application Databases#

4.1 Configure database backups#

1
Databases → select your database

1
# Production database (critical)
2
0 */6 * * *      # Every 6 hours
3

4
# Staging (medium importance)
5
0 2 * * *        # Daily at 2 AM
6

7
# Development (low importance)
8
0 2 * * 0        # Every Sunday at 2 AM
9

10
# High‑traffic workloads (e‑commerce / real‑time systems)
11
0 */3 * * *      # Every 3 hours

4.2 Test database backups#

Before relying on automated jobs, always run at least one manual test.

Steps:

1. Click Test backup
2. Watch the live logs to ensure the job completes successfully
3. Open the Cloudflare R2 bucket and confirm the backup file is there
4. Download the backup file and verify it extracts correctly and is not corrupted

1
dokploy-backups/
2
  └── prod-db/
3
      ├── postgres-backup-2025-11-12-00-00.sql.gz
4
      ├── postgres-backup-2025-11-12-06-00.sql.gz
5
      ├── postgres-backup-2025-11-12-12-00.sql.gz
6
      └── postgres-backup-2025-11-12-18-00.sql.gz

4.3 Commands Dokploy uses for database backups#

Dokploy runs native backup commands depending on the database type and uploads them to R2 as .gz compressed files.

1
pg_dump -Fc --no-acl --no-owner -h localhost -U ${databaseUser} \
2
  --no-password '${database}' | gzip

1
mysqldump --default-character-set=utf8mb4 -u 'root' \
2
  --password='${databaseRootPassword}' \
3
  --single-transaction --no-tablespaces \
4
  --quick '${database}' | gzip

1
mariadb-dump --user='${databaseUser}' \
2
  --password='${databasePassword}' \
3
  --databases ${database} | gzip

1
mongodump -d '${database}' -u '${databaseUser}' \
2
  -p '${databasePassword}' \
3
  --archive --authenticationDatabase=admin --gzip

4.4 Multiple database backups (multi‑project best practices)#

If you have multiple databases (microservices, multiple apps, multiple environments), create a separate backup job for each.

1
prod-web-app/
2
prod-analytics/
3
prod-auth/
4
dev-testing/

6. Volume Backups#

Step 5: Volume Backups#

Volume backups are for file‑based storage such as SQLite databases, uploads, config files, and static assets. For apps that don’t use an external database (e.g. n8n, Memos, Plausible, Umami), volume backups are critical for data safety.

5.1 When should you use volume backups?#

Volume backups are suitable for the following data types:

If your app stores data inside Docker volumes, you need volume backups.

5.2 Understanding Docker volume naming#

Before configuring volume backups, you must know the volume name. Volume names are usually tied to the app name and the Docker Compose structure.

1
App → Advanced → Mounts

1
app-data
2
uploads
3
config

1
{appName}_{volumeName}

5.3 Example: Backing up n8n (SQLite)#

n8n uses SQLite and stores data in a Docker volume, so you must use a volume backup instead of a database backup.

Example docker-compose.yml:

1
version: "3.8"
2
services:
3
  n8n:
4
    image: docker.n8n.io/n8nio/n8n:1.83.2
5
    restart: always
6
    environment:
7
      - N8N_HOST=${N8N_HOST}
8
      - N8N_PORT=${N8N_PORT}
9
    volumes:
10
      - n8n_data:/home/node/.n8n
11

12
volumes:
13
  n8n_data:

All critical data (workflows, users, history, SQLite DB) lives in the n8n_data volume.

5.4 Configure volume backups#

1
App → Volume Backups

5.5 Safety considerations: should you stop the container?#

5.6 How to find the correct volume name#

1
App → Advanced → Mounts

1
volumes:
2
  n8n_data:

1
docker volume ls

1
docker volume ls | grep n8n

1
docker volume inspect xxxx

7. Restoring Backups#

6.1.1 Restore steps#

6.1.2 Post‑restore checks#

• You may need to log in again
• All apps should appear in the dashboard
• Verify environment variables
• Test at least one app to ensure it runs correctly

Full migration checklist#

1. Update server IP#

Web Servers → Servers → Update IP address

2. Update DNS#

Point your domain A records to the new IP.
Wait 5–15 minutes for propagation.

3. Recreate Traefik.me domains (if used)#

Traefik.me will automatically bind to the new server IP.
You’ll need to recreate them for each app.

4. Fix Git provider webhooks#

If you previously used an IP, change it to the new IP or switch to a domain.

5. Verify SSL certificates#

Traefik will automatically request new Let’s Encrypt certificates.
The first issuance may take 5–10 minutes.

6. Check database connections#

Ensure all apps can connect to internal/external databases.

7. Health‑check your apps#

Open each app URL, test functionality, and read logs.

6.3.1 Restore steps#

1
prod-db/postgres-backup-2025-11-12-06-00.sql.gz

6.3.2 Verify the restore#

• Check DB logs for errors
• Confirm your app can use the database normally
• Verify critical records
• Ensure no connection errors appear in app logs

6.4.1 Restore steps#

6.4.2 Understanding volume names correctly#

1
n8n_data

1
n8n-kqlble_n8n_data

1
docker volume ls | grep n8n

6.4.4 Recommended full restore procedure#

1
# 1. Stop the app
2
docker compose -f /opt/stacks/n8n-kqlble/docker-compose.yml down
3

4
# 2. Remove the old volume
5
docker volume rm n8n-kqlble_n8n_data
6

7
# 3. Restore the volume backup in the Dokploy UI
8

9
# 4. Start the app
10
docker compose -f /opt/stacks/n8n-kqlble/docker-compose.yml up -d

6.4.5 Post‑restore checks#

• Container logs show no errors
• App starts successfully
• Restored data looks correct
• Full functionality works as expected