DEV Community: Kabeer N Shah

How We Built a 100% Free Disaster Recovery System for Our Client

Kabeer N Shah — Mon, 20 Apr 2026 18:05:28 +0000

When a client’s database is the heart of their business, a simple local backup isn't enough. If the server catches fire, the local backup burns with it. What they really needed was a Disaster Recovery (DR) System—a way to ensure that even in a worst-case scenario, their data is safe, off-site, and ready to be restored.

Standard cloud recovery plans can cost hundreds of dollars a month. However, after analyzing the client's data volume, we realized we could build a high-resilience system for $0/month using Docker, Google Drive, and rclone.

The Strategy: Off-Site Redundancy

A true Disaster Recovery plan follows the 3-2-1 Rule: 3 copies of data, on 2 different media, with 1 copy off-site.

Because our client had modest storage needs, we recommended skipping expensive enterprise vaults and instead using their existing 15GB of free Google Drive storage as their off-site DR site. It’s secure, global, and provides the redundancy needed to survive a local server disaster.

Step 1: The "Vault" (Docker)

We encapsulated the recovery tools into a Docker container. This ensures that the recovery process is portable; if the primary server fails, we can spin up this same "vault" on any other machine in minutes to begin the restoration.

To make it bulletproof on their Windows server, we baked the settings directly into the image. For example, here is a typical Dockerfile for this DR setup:

# Example Dockerfile
FROM alpine:3.18
RUN apk add --no-cache postgresql-client rclone bash ca-certificates
RUN mkdir -p /backups /config
COPY ./config /config
COPY ./scripts/backup-db.sh /scripts/backup-db.sh
RUN chmod +x /scripts/backup-db.sh
CMD ["/bin/bash", "-c", "while true; do /scripts/backup-db.sh; sleep 86400; done"]

Step 2: The "Bridge" (Rclone)

To move data to our off-site DR location, we used rclone.

The Challenge: Standard service accounts often have zero storage quota on personal accounts.
The Fix: We used an OAuth token, allowing the system to act as the client and utilize their full personal storage quota for disaster protection.

Important Security Tip for Windows Users:
If you're trying to generate your token and Windows blocks the connection, you may need to temporarily stop the service that "hogs" the network ports. Always remember to turn it back on immediately after to keep your system working correctly.

Stop the service: net stop winnat

Get your token: rclone authorize "drive"

Start the service back up: net start winnat

Step 3: Making it Permanent (The "Forever" Fix)

In a disaster recovery scenario, the last thing you want is a "broken link." Google tokens expire every 7 days in "Testing" mode. To ensure the recovery pipeline is always active, we "Published" the app in the Google Cloud Console. This ensures the refresh token lasts indefinitely, making the DR system truly "set-and-forget."

Step 4: The "Recovery Engine" (The Script)

We wrote a script that automates the daily protection cycle. It doesn't just copy files; it ensures data integrity by creating compressed, timestamped snapshots of the entire database.

# Example logic for the DR engine:
# 1. Snapshot the data for integrity
pg_dump -h db_host -U user -d database --file=backup.dump

# 2. Compress for faster off-site transfer
tar -czf backup.tar.gz backup.dump

# 3. Securely transfer to the off-site DR folder
rclone --config /config/rclone.conf copy backup.tar.gz gdrive:nordible/db-backups

The "Bonus" Feature: Automatic Retention

A good DR system stays lean. As a bonus, we added a cleanup rule that automatically deletes snapshots older than 5 days. This keeps the recovery site organized and ensures the client never hits a storage limit during a crisis.

The Result: Business Resilience

By combining these free tools, we achieved a professional-grade Disaster Recovery system.

Cost: $0/month.
Off-site Redundancy: Fully Automated.
Resilience: If the server goes down, the data is safe in the cloud.

Now, our client can sleep soundly knowing that even if disaster strikes, their business data is just a few clicks away from a full recovery.

How I Slashed API Latency by 80% (350ms -> 60ms) by Ditching Serverless

Kabeer N Shah — Sun, 25 Jan 2026 18:14:53 +0000

300ms to 60ms: How I Slashed API Latency by 80% with One Config Change

Kabeer N Shah ・ Jan 25

#devops #software #docker #performance

300ms to 60ms: How I Slashed API Latency by 80% with One Config Change

Kabeer N Shah — Sun, 25 Jan 2026 17:09:14 +0000

When migrating an application from a serverless environment to a dedicated cloud VPS, you expect a performance boost. After all, you're moving from transient functions to a persistent server.

But when I finished my migration recently, my health checks told a different story.

Despite my application server and managed database being hosted in neighboring regions, the database latency was consistently hovering around 300ms - 350ms. For a simple SELECT 1 query, that is an eternity.

Here is how I diagnosed the "Serverless Hangover" and reclaimed 80% of my performance.

The Investigation

Physics told me the connection should be fast. A standard network ping between the two servers showed a round-trip time of about 60ms.

So, why was my application reporting 350ms?

I looked at the usual suspects:

Resource Constraints: CPU and RAM usage were minimal.
Application Logic: The health check endpoint was as lean as possible.
Network Congestion: Consistent results across different times of day ruled this out.

The culprit was deeper: it was an architectural "best practice" that had become a bottleneck in a new context.

The Root Cause: The "Double Pooling" Trap

In a Serverless architecture, database connection management is a major challenge. Because functions spin up and down instantly, they can easily exhaust a database's connection limit. The standard solution is to use an external transaction pooler. This middleware sits between your functions and your database, managing a pool of persistent connections.

When I moved to a Persistent VPS (Docker), I kept using that same external pooler.

However, my new environment was fundamentally different. Unlike serverless functions, my Docker container stays alive. It uses an ORM with its own built-in, highly efficient connection pooling.

By pointing my persistent server to the external transaction pooler, I was effectively double-pooling. Every single query was forced through an extra middleware layer, incurring unnecessary SSL handshake negotiations and processing overhead, instead of holding a direct, persistent connection open.

The Fix

The solution was deceptively simple: Switch to the Direct Connection.

I updated my database connection string to bypass the external pooler and connect directly to the database server's standard port.

Before: App -> ORM Pool -> External Pooler (SSL Negotiation) -> Database
After: App -> ORM Pool (Persistent Connection) -> Database

The Result

The moment the change was deployed, the latency dropped from 350ms to 60ms.

By removing one unnecessary layer of "best practice" that no longer applied to my architecture, I achieved an 80% reduction in latency and a significantly snappier user experience.

The Lesson Learned

"Best practices" are not universal truths; they are context-dependent solutions.

What is a life-saver in a Serverless environment can be a performance killer in a Containerized one. Always audit your configuration and middleware when changing your underlying deployment architecture.

I'm currently building **HabitBuilder, a privacy-first habit tracker that focuses on flexible consistency rather than rigid streaks. Check it out at habits.planmydaily.com.