[FEAT] Extended Backup Scheduling and Cross-Server Restore Options #463

New Issue

MrUnknownDE · 2026-04-05T16:16:31+02:00

MrUnknownDE commented

2026-04-05 16:16:31 +02:00

Originally created by @Kauavitorio on 9/12/2025

Problem

Currently, Postgresus provides useful backup and restore capabilities, but there are some limitations that make it harder to adapt to real-world use cases:

Limited scheduling options – Users can only select predefined intervals, which does not always fit organizational needs.
Restore limited to same server – It is not possible to restore a backup taken from one server into another server/instance.
No API-triggered restore – Restores can only be initiated through the UI, which limits automation.

Proposal

1. Extended Backup Scheduling Options

Allow users to define a custom cron expression for backup jobs.
Alternatively (or additionally), provide richer built-in options such as:
- Running two backups per day.
- When selecting an Hourly interval, allow specifying which exact hours of the day backups should run.

This would help balance between resource usage and backup reliability.

2. Cross-Server Restore

Add support for restoring a backup from Server/Instance X into Server/Instance Y.
Example: In our environment we often restore the production database into the development server once a week, both to:
- Verify that backups are functional.
- Keep the DEV environment updated with fresh data.

Currently, this has to be done manually outside of Postgresus.

3. API-triggered Restore

Expose an API endpoint that allows triggering a restore operation via API call.
Use cases:
- Automated CI/CD pipelines that refresh test environments.
- Scheduled scripts that keep QA or DEV environments aligned with production.
- On-demand restores triggered by external systems.

Benefits

Greater flexibility in defining backup strategies.
Simplified workflows for environments with multiple servers (e.g., PRD → DEV refreshes).
Automation-friendly through API integration.
Increased reliability by making restore testing easier and more frequent.

This set of features would make Postgresus more versatile in complex environments and reduce manual effort in maintaining database reliability across multiple servers.

Additional Note

We are currently testing Postgresus within our infrastructure with a dedicated team of DBAs. The feedback so far has been very positive, as the tool has significantly streamlined their daily work.

Because of this successful experience, we are actively suggesting improvements and even considering asking our internal development team to contribute pull requests to the project. We see great potential in Postgresus and would like to help it grow further.

*Originally created by @Kauavitorio on 9/12/2025* ## Problem Currently, Postgresus provides useful backup and restore capabilities, but there are some limitations that make it harder to adapt to real-world use cases: 1. **Limited scheduling options** – Users can only select predefined intervals, which does not always fit organizational needs. 2. **Restore limited to same server** – It is not possible to restore a backup taken from one server into another server/instance. 3. **No API-triggered restore** – Restores can only be initiated through the UI, which limits automation. ## Proposal ### 1. Extended Backup Scheduling Options - Allow users to **define a custom cron expression** for backup jobs. - Alternatively (or additionally), provide richer built-in options such as: - Running **two backups per day**. - When selecting an *Hourly* interval, allow specifying **which exact hours of the day** backups should run. This would help balance between resource usage and backup reliability. ### 2. Cross-Server Restore - Add support for restoring a backup from **Server/Instance X** into **Server/Instance Y**. - Example: In our environment we often restore the production database into the development server once a week, both to: - Verify that backups are functional. - Keep the DEV environment updated with fresh data. Currently, this has to be done manually outside of Postgresus. ### 3. API-triggered Restore - Expose an API endpoint that allows triggering a restore operation via API call. - Use cases: - Automated CI/CD pipelines that refresh test environments. - Scheduled scripts that keep QA or DEV environments aligned with production. - On-demand restores triggered by external systems. ## Benefits - **Greater flexibility** in defining backup strategies. - **Simplified workflows** for environments with multiple servers (e.g., PRD → DEV refreshes). - **Automation-friendly** through API integration. - **Increased reliability** by making restore testing easier and more frequent. --- This set of features would make Postgresus more versatile in complex environments and reduce manual effort in maintaining database reliability across multiple servers. ## Additional Note We are currently testing **Postgresus** within our infrastructure with a dedicated team of DBAs. The feedback so far has been **very positive**, as the tool has significantly streamlined their daily work. Because of this successful experience, we are actively suggesting improvements and even considering asking our internal development team to contribute **pull requests** to the project. We see **great potential** in Postgresus and would like to help it grow further.

MrUnknownDE closed this issue

2026-04-05 16:16:31 +02:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/databasus#463