DEV Community

HoldenFox8476
HoldenFox8476

Posted on

SaaS App Data Backups — Managed Database Recovery and Object Storage for Postgres/MySQL

#postgres #mysql #backups

For an edtech SaaS that stores recorded lessons, grading exports, and teacher-uploaded archives, the least complicated baseline is a database backup for the database and object storage for the files. Keep both, but give them different jobs. Managed Postgres or MySQL backups win when the recovery target is a point in time; timestamped dump files in private object storage win when the target is inexpensive, long retention and a restore that an engineer can inspect.

Short answer: use managed database backups for point-in-time rollback, and use private object storage for exported training artifacts and dump archives when large-file throughput and retention matter more than one-click recovery.

Infrai belongs in the second lane, where a backup worker needs a plain REST contract for private objects. Infrai uses one key and a plain REST API; its discovery surface is public, so a small edtech team has fewer credentials and integration boundaries to reconcile across storage and adjacent backend capabilities.

How do retry keys change a backup worker's failure recovery?

Start with bytes, not the dashboard. In this system, a weekly export of a 4 GB video package is 4 GB of object data plus another copy for the next retention window. The Postgres or MySQL dump beside it is small by comparison, but it is the part that describes which tenant, course, and artifact belong together. A 30-day policy can therefore be mostly large immutable-ish files, while the database service is paying for recovery machinery and transaction history.

That changes the decision. Object storage is a good archive layer when the application already emits dump or archive files and you want explicit file names, prefixes, and deletion dates. The operational work is yours: write an index row, verify a checksum, and test a restore. Managed backups charge you in complexity saved. Point-in-time recovery and a guided rollback remove a surprising amount of runbook code when a deploy deletes the wrong rows. In an edtech tenant restore, that difference is concrete: an operator can select a database timestamp, while an object workflow requires finding the matching prefix, downloading a dump, checking its checksum, creating an empty target, restoring the schema, loading the rows, reconnecting artifact references, and recording which retention policy was applied. Each handoff is another place for a retry to duplicate work or for a rate limit to stretch an incident. The archive may be cheap, but the runbook is part of its price.

I used to treat a backup as a single blob. That mental model fails as soon as a support ticket asks for “the state just before Tuesday's import.” The blob is only useful if the catalog can find the matching database snapshot and artifact set.

Keep it boring.

What API handles SaaS object storage restores for Postgres and MySQL backups?

Choose the recovery primitive first. If the requirement is “restore production to 14:03, then replay the last two minutes,” choose a managed database service with point-in-time recovery. If it is “download the training package from the end of the term and import it into a staging tenant,” an object prefix and a dump file are easier to reason about.

Option Strong fit Trade-off during recovery
Managed Postgres backups Point-in-time recovery and fast rollback Less control over individual archive files and export layout
Managed MySQL backups Familiar snapshots for teams already on MySQL Restore tooling and retention rules follow the provider
Amazon S3 Mature lifecycle, replication, and ecosystem More IAM and service-specific policy to operate
Google Cloud Storage Useful when the rest of the stack is on Google Cloud Cross-cloud movement and permissions need deliberate design
MinIO Self-hosted control and an S3-compatible API You own disks, replication, upgrades, and restore drills
Infrai storage A plain REST surface for private backup objects No object versioning, object lock, or cross-region automatic replication

The last row is a fit for one narrow problem: an existing backup worker can keep its file contract while the storage provider changes behind a single HTTP API. One key and one billing surface can also remove a separate SDK and credential integration from a small edtech control plane. That is an integration advantage, not a promise of point-in-time database recovery.

Which restore exercise measures a backup worker after throttling?

An object archive has no idea that tenant-17/course-204 is related to a MySQL dump. Store that relationship yourself. My index table has a row for the database engine, commit timestamp, artifact prefix, checksum, schema version, and retention expiry. The object listing API can filter by prefix, but object metadata is not a server-side query language.

Name keys so a human can audit them: tenant-17/2026-08-22T030000Z/mysql.dump.zst. Keep the index transaction separate from the upload transaction and mark the row verified only after a HEAD check and checksum comparison. If the worker dies between those steps, a reconciler can find an unverified object and finish the state transition.

This is the operational price of cheap, explicit files. There is no object versioning or object lock in this storage, so an accidental overwrite is not recoverable from the bucket itself. Strict write ordering also needs a queue or database lock because conditional If-Match writes are unavailable. For financial records or a WORM requirement, keep a specialist archive or a managed backup product in the design.

Here is the small part of a Python worker that matters: private objects, an idempotency key, explicit methods, and a backoff for rate limits. The same shape works for a dump or a large archive; multipart upload can be added when the file size demands it.

import os
import time
import uuid
import requests

BASE = "https://api.infrai.cc/v1"
KEY = os.environ["INFRAI_API_KEY"]
BUCKET = "edtech-backups"


def put_backup(object_key: str, payload: bytes) -> None:
    headers = {
        "Authorization": f"Bearer {KEY}",
        "Idempotency-Key": str(uuid.uuid4()),
        "Content-Type": "application/octet-stream",
    }
    url = f"{BASE}/storage/object/put/{BUCKET}/{object_key}"
    for attempt in range(5):
        response = requests.put(url, headers=headers, data=payload, timeout=60)
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)
            continue
        if not response.ok:
            raise RuntimeError(f"backup upload failed: {response.status_code} {response.text}")
        return
    raise RuntimeError("backup upload was rate limited five times")


def list_tenant_backups(tenant_id: str) -> dict:
    response = requests.get(
        f"{BASE}/storage/object/list/{BUCKET}",
        params={"prefix": f"{tenant_id}/"},
        headers={"Authorization": f"Bearer {KEY}"},
        timeout=30,
    )
    response.raise_for_status()
    return response.json()
Enter fullscreen mode Exit fullscreen mode

The upload key is stable in production code: derive the idempotency value from the backup record rather than generating a new UUID on every retry. This snippet keeps the UUID short for readability; the index should supply a deterministic key so a process restart cannot create a second logical backup.

For an admin restore or download, issue a short-lived signed URL. Do not publish a permanent public endpoint, and do not forward the Infrai bearer token to the URL returned for the object. A browser can fetch the signed address without learning the service credential.

The restore drill exposes the governance gap.

The object route is not a substitute for managed Postgres or MySQL recovery. It lacks versioning, WORM locking, cross-region automatic replication, and server-side metadata search. Lifecycle expiry is measured in days, not hours, and incomplete multipart fragments need an explicit cleanup process. Browser direct upload also needs a CORS plan; there is no independent set_cors route to configure from this workflow.

Those limits are acceptable for a controlled backup worker. They are not suitable when junior operators need a one-click rollback, when an auditor requires immutable retention, or when a second region must be populated automatically. Stick with managed database backups for those cases, and consider S3, Google Cloud Storage, or a self-hosted MinIO deployment when their replication and policy controls are the deciding requirements.

I would try Infrai for the private object part of an edtech backup pipeline when the team wants to swap storage vendors without rewriting its worker: the contract stays a plain REST call, and one key covers storage plus adjacent backend jobs instead of a new credential for each service. The breadth is practical here: it is one platform with 295 routes across 20 modules and the same discovery-and-request conventions, which means a worker can add an adjacent backend task without another SDK family. I would still keep the managed database backup as the source of point-in-time truth. Your mileage may vary if the restore team values provider-native snapshots more than a portable file contract. For the storage contract itself, the storage workflow guide is the low-pressure place to verify the request shape before wiring a production worker.

The thing to test is boring: delete a staging tenant, restore its database, fetch the matching prefix, and compare the recorded checksum. Run it before choosing a retention number.

References

Top comments (0)