Disaster recovery (DR) / cold-tier backup to DePIN

Expiremental Guide: May contain errors as our technology continues to evolve. If you encounter any problems, please do not hesitate to contact us in Discord and give us your feedback.

The Problem

Relying on a single cloud for backups risks vendor outages, policy changes, and pricey “rehydration” from cold tiers. Building a cross-cloud (or DePIN) backup pipeline usually means stitching together different SDKs, auth models, and copy rules, plus figuring out when you’ll pay egress.

Flashback simplifies this: attach your hot bucket and a cheaper cold bucket to one Repository, then copy with a single client. When source/destination allow it, Flashback uses the provider’s native copy (S3 CopyObject, GCS RewriteObject, Azure copy_from_url) to avoid traffic charges; otherwise the Bridge Node emulates the copy by streaming bytes between buckets. You can test which path you’re taking on a tiny object and verify billing before moving real data.

---

Step-by-Step Deployment Recommendations

1

Define your Backup policy

• Frequency & scope: e.g., run hourly/daily on prefixes like app-data/ and db-dumps/.

• Retention: decide how long to keep in cold tier (by prefix/date).

• Large objects: default per-file operation limit is 100 MB; plan multipart/resumable uploads for larger backups.

• Tracking: keep a small manifest/checkpoint (written to your Repo) to avoid recopying objects.

2

Create Buckets & Repository in Flashback

• Create/Link Cloud Buckets in Flashback

  • For each provider, add a Bucket in the dashboard: “Add Bucket” → select provider → provide credentials/role → validate.

  • Select DePin providers for cold storage. Be aware of latency increase.

• Create a Repository

  • “New Repository” → name it (e.g., app-data) → attach all created Buckets.

• Generate Repository API Keys

  • Create a WRITE key for your application and a READ key for services that only read.

  • Save the secret in your vault; you can’t retrieve it later from it.

3

Wire your backend client to Flashback

Create clients pointing at a Bridge Node endpoint; keep a small cache keyed by endpoint so you can swap quickly.

Python (boto3 / S3)

# fb_s3_client.py
import boto3
from botocore.client import Config

def s3_client_for(endpoint, key_id, key_secret):
    session = boto3.session.Session(
        aws_access_key_id=key_id, aws_secret_access_key=key_secret
    )
    return session.client("s3", endpoint_url=endpoint, config=Config(signature_version="s3v4"))

Node (aws-sdk v3 / S3)

// fbS3Client.ts
import { S3Client } from "@aws-sdk/client-s3";

const clients = new Map<string, S3Client>();
export function s3ClientFor(endpoint: string, keyId: string, secret: string) {
  if (!clients.has(endpoint)) {
    clients.set(endpoint, new S3Client({
      endpoint, region: "us-east-1",
      credentials: { accessKeyId: keyId, secretAccessKey: secret },
      forcePathStyle: true
    }));
  }
  return clients.get(endpoint)!;
}

(Use analogous clients for GCS/Azure if that’s your app’s native protocol.) Flashback S3 endpoints are compatible with standard S3 SDKs.

4

Implement the backup job (baseline)

A. Choose the copy path per pair of buckets

• Native copy (lowest cost): only if same storage type & provider and provider rules (region/class/size) allow it. Signaling rules: • S3/Azure Blob → destination attached, source not, dest creds can read source. • GCS → source attached, destination not, source creds can write to destination.

• Emulated copy (cross-provider): attach both buckets to the Repo; Flashback streams data between them. Expect egress + Flashback traffic counted.

B. Enumerate & copy

• Scan the hot bucket for new objects since your last checkpoint (manifest stored in the Repo).

• For each object, try native copy when eligible; otherwise let Flashback emulate the copy. Native copies typically avoid traffic charges; emulated copies always bill egress.

C. Schedule

• Run via cron/K8s Jobs/Cloud Scheduler. Persist checkpoint after each successful batch.

Tip: Before the first full run, test with a tiny file and check the provider console for any traffic charges. This confirms whether you’re on the native or emulated path.

5

Monitoring & alerts

• Pull daily and minute stats to track ops, latency, and errors. JWT Bearer required. GET https://backend.flashback.tech/stats/daily · GET https://backend.flashback.tech/stats/minute

• For per-node visibility (e.g., targeting a specific bucket/region), use GET /stats/nodes/minute?bucketId=....

const H = { Accept: "application/json", Authorization: `Bearer ${process.env.FB_JWT}` };
const daily  = await fetch("https://backend.flashback.tech/stats/daily",  { headers: H }).then(r=>r.json());
const minute = await fetch("https://backend.flashback.tech/stats/minute", { headers: H }).then(r=>r.json());

6

Restore drills (don’t skip!)

• Periodically restore a random sample from the cold tier to prove integrity and measure RTO.

• Remember: some bucket-level features (e.g., versioning, lifecycle rules) are not managed via Flashback endpoints—plan your policy at the provider.

7

Validate & roll out

• Smoke test: Put/Get/Delete via Flashback to both buckets.

• Cost probe: tiny copy + console check confirms native vs emulated path.

• Gradual rollout: start with low-risk prefixes; then widen.

8

Operation Playbook

• Keys: rotate Repo keys; secrets are encrypted and not recoverable after creation.

• Quotas: set a monthly limit; if QUOTA_EXCEEDED, treat Repo as read-only until reset or limit raised.

• Endpoint choice: prefer the closest Bridge Node; bucket details show node Online/Disconnected/Offline and HeadBucket latency to guide routing.

• Large files: plan multipart/resumable for objects over 100 MB.