a month ago
Hello Railway team. We use Hobby with official PostgreSQL 18. The authenticated Backups page says backups/PITR require Pro; nothing is being enabled or upgraded. Before choosing a retention policy, we need staff clarification of when recovery becomes impossible, not merely when an item disappears from the UI.
-
For scheduled, manual and locked volume snapshots, what happens on nominal expiry versus explicit deletion? The API returns a workflow ID. What is the maximum time until neither the customer nor Railway Support can restore the snapshot, and what supported check proves that point?
-
For Auto Update/pre-update volume backups, what is the exact TTL? Can they be locked, do they appear in the ordinary backup list and count toward plan limits, and do they have the same deletion/finality rules?
-
Are any customer-data copies recoverable through Support or platform recovery after removal from ordinary backup/volume inventory? Please distinguish those from internal redundancy that cannot restore an individual deleted database, and state any maximum retention.
-
The official postgres-ssl implementation uses count-based pgBackRest retention after successful backups, with expiry failures deferred to a later backup; it documents old cluster prefixes surviving major upgrades without automatic expiry. Is there any independent platform cleanup or hard maximum age, including when the service is stopped? How should operators discover every still-restorable history?
-
For individual PITR backup/WAL objects or an explicitly deleted old history prefix, is there a recovery grace period or Support recovery after deletion? How can final unrestorability be verified? Please distinguish this from the documented two-day whole-bucket recovery window and PITR disablement with a preserved bucket.
-
Do PITR restore siblings persist without automatic expiry? Does deleting a service remove its attached AND previously detached volumes, or must each be deleted separately? How can operators inventory and verify destruction of all related resources, including soft-deleted ones?
Relevant docs: https://docs.railway.com/volumes/backups and https://docs.railway.com/volumes/point-in-time-recovery . If a guarantee or verification mechanism is unavailable, please say so explicitly. No account/configuration changes are requested.
2 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
One related documentation discrepancy for question 6: the PITR guide says restored forks are non-archiving until PITR is enabled separately, but the official postgres-ssl README at commit 6590549a7e6f41306d44c70899a4b50414fc0a20 describes a fresh destination bucket and archiving from boot, with no separate re-enable step. Which behavior does the current standalone restore workflow actually provision? Any automatically created fork bucket, backups and WAL must also be included in the recovery-resource inventory. Source: https://github.com/railwayapp-templates/postgres-ssl/blob/6590549a7e6f41306d44c70899a4b50414fc0a20/README.md
20 days ago
Terimakasih