Backups & Restore

Overview

Zektor.io PostgreSQL databases include comprehensive backup and restore capabilities to protect your data. The backup system provides both automated scheduled backups and manual on-demand backups, as well as point-in-time recovery (PITR) support through Write-Ahead Log (WAL) archiving.

Automatic Scheduled Backups

Default Backup Schedule

Every PostgreSQL instance comes with a default backup schedule that takes daily base backups. This ensures you always have a recent recovery point — no setup required.

Custom Backup Schedules

You can create custom backup schedules from the Backups tab:

• Frequency — Configure how often backups run (hourly, daily, weekly, monthly, or custom cron)
• Time — Specify when the backup should start
• Retention — How long to keep backups before automatic cleanup (hours, days, weeks, months, or years)
• Name — Optional name for the schedule (auto-generated if left blank)

To create a schedule:

1. Navigate to the Backups tab
2. Click Create Schedule
3. Configure the frequency, time, and retention settings
4. Click Create

Additional Backup Schedules

You can create multiple backup schedules for the same instance (up to 5 per instance). For example:

• A daily backup with 7-day retention for quick recovery
• A weekly backup with 90-day retention for compliance
• A monthly backup with 1-year retention for archival

Manual Backups

You can trigger a one-time backup at any time:

1. Navigate to the Backups tab
2. Click Create Backup
3. The backup will begin immediately

Manual backups are useful before making significant schema changes or data migrations. You can have up to 10 active manual backups per instance.

Viewing Backups

All backups are listed in the Backups tab with:

You can filter backups by branch using the branch selector.

Backup size

Backup size may differ from your actual database size due to compression. Typically, backups are 30-60% smaller than the source database depending on data compressibility.

Failed backups

If a backup shows "Failed" status:

• The system will automatically retry on the next scheduled run
• You can manually trigger a new backup immediately
• Persistent failures may indicate storage pressure — check your monitoring dashboard

Restoring from Backups

Creating a Restored Branch

When you restore a backup, Zektor.io creates a new branch with the data from that backup. Your original database is never modified.

To restore from a base backup:

1. Find the backup in the Backups tab
2. Click Restore on the backup entry
3. Configure:
   • Branch name — Name for the new branch
   • Cluster size — Choose the compute tier for the restored branch
4. Click Restore

Point-in-Time Recovery (PITR)

PITR allows you to restore your database to any specific point in time between your oldest backup and now. This uses WAL (Write-Ahead Log) archiving to replay transactions up to the exact moment you specify.

PITR is essential for:

• Recovering from accidental DELETE or DROP statements
• Rolling back data corruption to the exact moment before it occurred
• Precise recovery that base backups alone cannot provide

To use PITR:

1. Navigate to the Backups tab
2. Click Restore Backup
3. Select the exact date and time to restore to
4. Choose a cluster size and optionally set a branch name
5. Click Restore

Important: The target restore time must be at least 2 minutes in the past to ensure WAL segments are fully archived.

How PITR Works

1. The system identifies the most recent base backup before your target time
2. That base backup is restored to a new branch
3. WAL (Write-Ahead Log) segments are replayed up to your exact target timestamp
4. The new branch becomes available with your data at that precise moment

Restored Branch Behavior

• Restored branches are independent — They function as separate database instances
• Data is preserved — All data up to the restore point is included
• Extensions need reinstallation — PostgreSQL extensions may need to be reinstalled on the restored branch
• New credentials — The restored branch gets its own connection credentials
• Independent billing — The restored branch is billed based on its cluster size

WAL Archiving

PostgreSQL continuously archives Write-Ahead Log (WAL) segments. These segments record every change made to your database and enable point-in-time recovery.

WAL storage is separate from your database storage and is monitored via the WAL Storage metric in your instance dashboard.

Backup Retention

Backups are automatically cleaned up based on the retention policy of their schedule:

Note: Deleting a backup schedule does not immediately delete existing backups — they will be cleaned up according to their original retention period.

Best Practices

1. Enable at least one automated backup schedule — Don't rely on manual backups alone
2. Use multiple schedules — Combine frequent short-retention backups with less frequent long-retention ones
3. Test restores regularly — Periodically restore from a backup to verify your data is recoverable
4. Monitor backup status — Check the Backups tab to ensure backups are completing successfully
5. Use PITR for precision — If you know the exact time of an incident, PITR gives you the most granular recovery
6. Back up before major changes — Take a manual backup before schema migrations or large data operations
7. Keep backup retention aligned with requirements — Don't over-retain (cost) or under-retain (risk)

Next Steps

• Branching — Understand how restored branches work
• Monitoring — Monitor WAL storage and backup metrics
• Scaling — Choose the right cluster size for restored branches
• Limits & Quotas — Backup schedule and retention limits