DEV Community: Takiuddin Ahmed

A backup you haven't restored isn't a backup

Takiuddin Ahmed — Sun, 09 Aug 2026 18:00:14 +0000

Migrating from MongoDB Atlas to a self-hosted replica set bought us control and cut our bill. It also quietly removed something we had stopped thinking about: Atlas had been taking continuous backups for us the entire time.

After the migration, production data for Prochesta lived in /var/db/mongo on a single VPS. No snapshots. No off-box copy. A rm -rf, a bad migration script, or a dead disk would have been the end of it. We had written "backups" as a follow-up task in the migration spec, which is the engineering equivalent of a sticky note on a bank vault.

The requirement we actually cared about was narrower than "back up the database". Most real-world data loss at our scale isn't hardware failure — it's a deploy that writes garbage, or someone running an update without a filter. Recovering to last night doesn't help when the damage happened at 14:20 and you noticed at 14:50. We needed to recover to an arbitrary moment, not to a nightly snapshot.

The constraint nobody mentions: Community has no `$backupCursor`

We chose Percona Backup for MongoDB (PBM), and immediately hit the limitation that shapes every decision downstream.

PBM offers physical backups — fast file-level copies that restore in minutes and barely touch the running server. They work by opening a backup cursor via the $backupCursor aggregation stage. That stage exists in Percona Server for MongoDB and in MongoDB Enterprise. It does not exist in MongoDB Community, which is what the official mongo:8.0 image ships.

So on Community, PBM gives you logical backups only: every document read out through mongod, compressed, and shipped off-box. Two consequences, both accepted deliberately rather than discovered later:

Backups cost CPU on the primary — and with a single-member replica set there's no secondary to offload the read to.
Restores insert documents and rebuild indexes, so restore time grows with data size much faster than backup time does.

At our current size that's minutes, not hours. It's also the thing that will eventually justify swapping the image for Percona Server. Knowing which constraint will force the next migration is worth more than pretending there isn't one.

We had already built one of these. We didn't use it.

I maintain mongopit, a self-hosted MongoDB point-in-time recovery tool. Its architecture is the same shape as what we ended up with: mongodump --oplog for consistent full snapshots, a daemon tailing the oplog and streaming compressed BSON segments to cloud storage, and mongorestore --oplogReplay --oplogLimit to stop the replay just before the operation that ruined your day. It ships GFS retention, a --dry-run restore preview, and runs as a single Docker Compose service.

It stores backups on Google Drive via rclone. That's the reason we reached for PBM instead — we wanted Cloudflare R2 as a first-class target, and the reasons are worth spelling out because they aren't really about Drive.

The data was already there. Prochesta serves user uploads, receipts and generated PDFs from R2 through the S3 SDK. Same account, same credentials, same billing, same dashboard we already check during an incident. Adding Google Drive meant a second provider, a second service account, and a second thing to be wrong at 3am.

R2 has zero egress fees, and that's a reliability feature, not a line item. Restore rehearsals pull the entire backup down. If every drill has a bandwidth cost attached, drills quietly stop happening — and an unrehearsed backup is a rumour. We wanted the cost of practising to be zero so there's never a reason to skip it.

Object storage semantics beat file-sync semantics for this job. S3-style multipart uploads, predictable API rate limits, and a flat key namespace are what an unattended nightly job wants. Drive service accounts bring their own operational texture: daily transfer ceilings, the shared-drive requirement for service accounts, and API quota errors that surface as a failed backup rather than a slow one.

PBM speaks S3 natively, so R2 needs configuration, not a translation layer. rclone's S3 backend could in principle point mongopit at R2 — but that's a path the tool wasn't built or tested around, and we'd be maintaining it ourselves.

None of this makes mongopit the wrong choice. If Drive is where your storage budget already lives, or you want something small enough to read end to end in an afternoon, it does the job and it does point-in-time properly. Ours was a storage decision, not a verdict on the tool.

What actually runs

┌──────────── VPS ─────────────┐
│  mongod (rs0, 1 member)      │
│      ▲                       │
│      │ logical read          │
│  pbm-agent ──── full backup daily 20:00 ────┐
│      └───────── oplog slice / 10 min ───────┤
│                              │              ▼
│  host cron                   │      Cloudflare R2
│   ├─ backup  20:00           │      one bucket
│   └─ metrics every 5 min     │      ├── prod/
│         │                    │      └── dev/
│         ▼                    │
│  pbm-metrics.sh              │
│   (pbm status -o json → .prom)
│         │                    │
│         ▼                    │
│  node_exporter → Prometheus → Alertmanager → email
└──────────────────────────────┘

One bucket, two prefixes, one guard

Dev and prod write into the same R2 bucket, separated by a key prefix. One bucket means one token, one lifecycle policy, and one place to look. It also means a misconfigured dev box could write into production's backup path — and, worse, prune it, since retention deletes anything older than the window.

So the bootstrap script doesn't trust the config file it just sent. It asks PBM what it actually stored, and refuses to continue if the prefix isn't the one this box is supposed to own:

applied_prefix="$(pbm_config_value storage.s3.prefix)"
[[ "$applied_prefix" == "$PBM_R2_PREFIX" ]] || die "..."

Configuration that verifies itself is the difference between a safety property and a naming convention.

The R2 specifics, for anyone doing the same:

storage:
  type: s3
  s3:
    region: auto          # R2's only valid region
    endpointUrl: https://<ACCOUNT_ID>.r2.cloudflarestorage.com
    forcePathStyle: true  # PBM's default; pinned so it stays true
    bucket: prochesta-mongo-backups
    prefix: prod          # or dev

Seven days of snapshots, two days of moments

	Retention	Granularity
Full backups	7 days	one per night at 20:00
Oplog slices	2 days	every 10 minutes

Inside two days we can restore to any instant — 14:19:59, one second before the bad write. Beyond that we have nightly snapshots for a week. Corruption discovered on day three costs up to 24 hours of data; corruption discovered within two days costs seconds.

The two windows are coupled in a way that's easy to get wrong. Point-in-time recovery replays oplog slices on top of a full backup. If the oplog window were shorter than the interval between backups, the newest snapshot would have no slices behind it and PITR would silently degrade to "restore last night". Our backup script refuses to run if that invariant is ever violated in config.

The dead man's switch

Percona ships a PBM collector for mongodb_exporter. We deliberately didn't use it.

It reports what PBM's own collections say — agent status, backup sizes, transition timestamps. All useful. But consider how a backup system actually fails in production:

The cron entry gets wiped during a host rebuild.
The pruning step starts erroring while the backup itself still succeeds.
Someone runs a restore, which turns PITR off, and nobody re-enables it.

In every one of those cases the exporter keeps reporting a healthy last backup, because the last backup was healthy. It just happened eleven days ago.

Instead, one script parses pbm status -o json into a Prometheus textfile every five minutes:

prochesta_pbm_metrics_scrape_ts       1754337900
prochesta_pbm_last_backup_success_ts  1754337005
prochesta_pbm_pitr_last_chunk_ts      1754337600
prochesta_pbm_agents_ok               1

That first timestamp is the whole idea. If the monitoring itself dies, the value stops moving and PBMMetricsStale fires within fifteen minutes:

- alert: PBMMetricsStale
  expr: absent(prochesta_pbm_metrics_scrape_ts)
        or (time() - prochesta_pbm_metrics_scrape_ts) > 900
  for: 10m

Without it, a dead cron job is indistinguishable from a healthy system: no errors, no alerts, no backups. The runbook says to check that alert first, because while it's firing every other backup metric is frozen at a stale value and telling you nothing about now.

The script always writes its file — especially when everything is broken. If PBM is unreachable it writes prochesta_pbm_up 0 and moves on. Going silent on failure would be the one behaviour that defeats the entire purpose.

Twelve rules sit on top of those metrics. The one we expect to earn its keep least often is the most interesting: PBMBackupSizeCollapsed fires when a backup succeeds but comes in at under half its seven-day average — the shape of a backup that completed and is missing most of the data.

Two traps in the restore path

A logical restore can't run against a cluster that's being written to. So restores are a downtime event, and the script owns that explicitly: it stops the API container, restores, and brings it back on every exit path — a failed restore must not also leave the site down.

The second trap is nastier. A restore turns PITR off, and the restored state has no full backup behind it. Point-in-time coverage is gone, but pbm status still cheerfully lists all the older backups, so nothing looks wrong. Re-enabling PITR and taking a fresh base backup is therefore built into the restore script as its final step, not written down as something an operator is expected to remember at the end of an incident.

Four things that broke

Everything above validated cleanly — compose files parsed, promtool passed, the metrics parser was tested against fixtures built from PBM's own source. Then we ran it on a real box.

1. The deploy started an agent that couldn't authenticate. Our deploy script ends with docker compose up -d --wait. On a box that had never been through backup setup, that started pbm-agent with an empty password. It failed its healthcheck, went unhealthy, and failed the entire deploy — on a host that simply wasn't using backups yet. Fix: put the backup services behind a compose profile so the default service set excludes them entirely.

2. Setup succeeded without doing anything. The setup script preserved existing values in .env, which is correct for passwords and wrong for a feature flag. With PBM_ENABLED=false already set, every subsequent step no-opped, the verification backup exited zero without backing anything up, and the closing report announced that backups were configured. Running the setup script is the request to enable backups, so it now forces that value.

3. PBM returns config values in brackets. Our prefix guard compared pbm config storage.s3.bucket against the expected name. PBM 2.15 returns [storage.s3.bucket=prochesta-mongo-backups], not a bare value, so the comparison never matched and bootstrap aborted on a box where the configuration had applied perfectly. The same bad parse silently reset PITR on every run.

4. The restore prompted into a pipe. pbm restore asks "Are you sure?" before dispatching. We invoke it through docker compose exec -T, which allocates no TTY, so it died with Error: no tty — after our script had already stopped the API. The confirmation happens before the restore is dispatched, so nothing was touched, but our error message claimed the database was "in whatever state the restore reached". The fix is one flag. The lesson is that a restore path you have never executed is not a restore path.

Why 517 MB of database is a 75 MB backup

The first production backup came in at 74.98 MB against a data directory of 517 MB, which is exactly the kind of number that makes you want to verify before trusting. It decomposes cleanly:

Component	Size	In a logical backup?
WiredTiger journal	201 MB	No
Oplog (`local` db)	120 MB	No
Diagnostic data	8.8 MB	No
Collections + indexes on disk	184 MB	Documents only
Data directory total	517 MB	→ 74.98 MB shipped

A logical backup carries documents, not storage. Indexes are rebuilt at restore time from their definitions rather than copied. The journal and oplog are working state. What remains is BSON compressed with s2 — and 184 MB of on-disk collections and indexes reducing to 75 MB is precisely what you'd expect.

Arithmetic like this rules out the blunt failure — a backup that ran and captured almost nothing. It proves nothing about whether the backup restores.

What we haven't solved

Automated restore verification doesn't exist yet. Nothing on a schedule restores the latest backup into a throwaway instance and asserts that collection counts match. Until that exists, every backup is unproven except the ones a human has personally drilled. This is the single highest-value thing left, and PBMBackupSizeCollapsed is a deliberately crude stand-in for it.

The backups share the application's R2 credentials. Anything holding that key — including the running API container — can delete every backup, and R2 offers no object versioning or object lock to fall back on. We took this knowingly to limit secret sprawl, and built the seam for the fix: dedicated PBM_R2_* keys take precedence over the shared ones, so moving to a bucket-scoped token is three lines of config and no code change. Naming the risk in the spec isn't the same as removing it.

Two days of point-in-time is short. Corruption noticed on day three falls back to a nightly snapshot. Widening it costs only R2 storage — we start narrow and widen when something teaches us to.

Design for the failure you'll actually have

The interesting decisions here weren't about backup software. They were about which failure we believed would happen.

We assumed the cron would silently stop long before we assumed the disk would die, so we built a dead man's switch before we built a second storage region. We assumed someone would eventually run a restore against the wrong environment, so the prefix guard aborts rather than warns. We assumed drills would stop happening if they had a cost, so we chose storage with zero egress.

Every one of the four rollout bugs was in the operational scaffolding — the deploy interaction, the flag handling, the output parsing, the TTY — and not one was in the backup engine. That's where these systems break, and it's why "we configured backups" and "we have backups" are different sentences.

Built at Prochesta — an exam preparation platform for students in Bangladesh, with model tests, live exams, friendly battles and performance tracking. The infrastructure above is what keeps their attempt history, results and subscriptions safe.

And if Google Drive is where your backups belong, take a look at mongopit — self-hosted MongoDB point-in-time recovery, oplog replay and GFS retention, in one Compose service.

Nightly backups aren’t enough when someone drops the wrong MongoDB collection. I built an open-source PITR system using oplog replay, Docker, and Google Drive - so you can restore to the second before disaster. Feedback welcome!

Takiuddin Ahmed — Fri, 24 Jul 2026 13:14:33 +0000

Takiuddin Ahmed

Jul 24

How I Built a MongoDB Backup System That Can Undo an Accidental Drop

#mongodb #backup #docker #python

7 min read

How I Built a MongoDB Backup System That Can Undo an Accidental Drop

Takiuddin Ahmed — Fri, 24 Jul 2026 10:58:18 +0000

Every developer has the same nightmare. Someone runs a command on the wrong database, a collection gets dropped, and suddenly the data is just gone. Your last backup was from midnight, so you can restore that, but you still lose everything that happened after midnight.

I wanted something better. Not just "restore last night's backup" but "restore the database to the exact second before the drop happened." That feature has a name: point-in-time recovery, or PITR. This post is about how I built it, and the one small MongoDB fact that makes the whole thing possible.

The project is open source and called mongopit. You can find it here:

https://github.com/takiuddinahmed/mongopit

The core problem

A normal backup is a photo. You take one at midnight, another at noon, and if something goes wrong at 11am you are stuck with the midnight photo. Everything between midnight and 11am is lost.

Point-in-time recovery is more like a video. You keep the midnight photo, but you also record every single change after it. When disaster strikes, you can play the video forward and stop it one frame before the bad thing happened.

In MongoDB, that "video" already exists. It is called the oplog.

The one fact that changes everything

The oplog (operations log) is an ordered record of every write MongoDB makes. Every insert, update, and delete goes into it. If you have the oplog, you can replay history.

Here is the catch that surprises a lot of people. A standalone MongoDB server has no oplog. The oplog only exists on replica set members. So if you are running a plain single MongoDB, you cannot do point-in-time recovery at all, no matter what backup tool you use.

The fix is simple and it does not need extra servers. You run your MongoDB as a single-node replica set. It is still one machine, one process, one data directory. You just turn replication on. That one change gives you an oplog, and the oplog gives you PITR.

This is the reason the whole system is shaped the way it is. If you ever see the setup and think "why not just run it standalone," this is why.

How the recovery actually works

The system has two things running at all times.

First, a scheduled full backup. This uses mongodump --oplog to take a consistent snapshot of everything. Before the dump, it records the current oplog position. Think of this as the photo, plus a note saying "this photo was taken at frame 5000."

Second, a continuous oplog tailer. This is a small process that watches the oplog and keeps copying new operations into files. It runs all the time, flushing every few seconds. This is the video recording that never stops.

Both of these get compressed and shipped off to storage.

When you need to recover, three steps happen:

Find the most recent full backup taken before your target time. Restore it. Now you have the database as it was at the photo.
Gather all the recorded oplog operations between the photo and your target time.
Replay those operations, but tell MongoDB to stop just before the target timestamp.

That last part is the magic. mongorestore has a flag called --oplogLimit, and it is exclusive. Any operation at or after that timestamp is skipped. So if you set the limit to the exact timestamp of the drop, the replay stops right before it. The drop never happens in your restored copy. Everything up to that instant is saved.

To find that exact timestamp, the tool has an inspect command that scans the oplog and shows you destructive operations like drops and deletes, with the precise timestamp to stop before. You copy that timestamp, paste it into the restore command, and you are done.

Why replaying the same data twice is safe

You might notice a small overlap. The full backup already contains some oplog data, and then we replay external oplog on top of it. Are we not applying some operations twice?

Yes, and it does not matter. MongoDB's oplog replay is idempotent. Applying the same operation twice gives the same result as applying it once. Inserts become upserts, and so on. This is a nice property because it means restarts and overlaps never corrupt the result. It also means I did not have to write clever code to track exactly-once delivery, which is where bugs love to hide.

Where the backups go

I wanted to store backups on Google Drive, mostly because it is cheap and easy for a small setup. No mainstream backup tool supports Google Drive directly, so I used rclone, which speaks to dozens of storage backends including Drive.

Everything that touches storage goes through one thin wrapper around the rclone command line, with retries and backoff built in. There is no separate database or index tracking what backups exist. The storage itself is the source of truth. To figure out what is available, the system just lists the files. Full backups live in one folder, oplog segments in another, and the file names carry the timestamps. Fewer moving parts means fewer things that can drift out of sync.

A few things I learned building it

Timestamps show up in three different shapes. One format for file names, one for the restore command line, and one for the metadata files. I kept getting them mixed up until I wrote small helper functions for each and used them everywhere. If you deal with MongoDB timestamps, do this early.

Retention is easy to get wrong in a dangerous way. I used a grandfather-father-son policy, keeping some daily, weekly, and monthly backups. The important rule is that you must never delete oplog segments if they still have no full backup to sit on top of. An oplog segment with no base to apply onto is useless. Prune in the wrong order and you quietly destroy your ability to recover.

A backup you have never restored is not a backup. It is a hope. So the system has a verify step that spins up a throwaway MongoDB container, restores the latest backup into it, checks that the data is actually there, and then throws the container away. If that ever fails, you find out on a normal Tuesday instead of during a real emergency.

The whole thing runs in Docker

Everything ships as a Docker Compose stack. There is the MongoDB container running as a single-node replica set, and one backup agent container that does three jobs in one process: it makes sure the replica set is initiated on startup, it runs the oplog tailer in a background thread, and it runs the scheduler for full backups, retention, and verification. I started with three separate services and combined them into one. The memory savings are modest, but the simplicity is real.

How to actually use it

Here is what running the tool looks like in practice.

Step 0: Get it.

Clone the repository and you have everything you need. It ships as a Docker Compose stack, so you do not have to install Python or MongoDB tools by hand.

git clone https://github.com/takiuddinahmed/mongopit.git
cd mongopit

Step 1: Point it at your MongoDB and storage.

Everything is driven by a .env file and an rclone.conf. You tell it your MongoDB connection string, your rclone remote (like Google Drive), how often to run full backups, and how many daily, weekly, and monthly copies to keep.

If your MongoDB is currently standalone, you do a one-time conversion to a single-node replica set. Stop it, start it again with --replSet rs0, connect with mongosh, and run this once:

rs.initiate({ _id: "rs0", members: [{ _id: 0, host: "yourhost:27017" }] })

Your data stays exactly where it is. The oplog starts recording from that moment.

Step 2: Start the stack.

docker compose up -d --build

That brings up MongoDB and a single backup agent. The agent initiates the replica set if needed, starts recording the oplog, and schedules your full backups, cleanup, and verification. From here it runs on its own.

Step 3: Take a backup now if you want one.

You do not have to wait for the schedule. You can trigger a full backup any time:

docker compose exec backup-agent mongopit backup-full

Step 4: When something bad happens, find the moment.

Say a collection got dropped. First you look at the recent history to find the exact timestamp of the drop:

docker compose exec backup-agent mongopit inspect

This prints recent destructive operations with a value called oplogLimit next to each one. That value is the timestamp you will recover up to.

Step 5: Recover to just before it.

Take the timestamp from the previous step and pass it to the restore command:

docker compose exec backup-agent mongopit restore \
  --target-uri "mongodb://mongo:27017/?replicaSet=rs0" \
  --point-in-time 1721800020:1 \
  --drop

Because the limit is exclusive, the drop is never replayed. The collection comes back with every document that existed the instant before it was dropped.

A good habit: run it with --dry-run first. That prints the plan, which base backup and which oplog segments it will use, without touching any data. When you are happy, run it for real. If you are nervous about production, restore into a scratch database first and check it there.

Other commands you will use.

# apply retention now instead of waiting for the schedule
docker compose exec backup-agent mongopit prune

# prove your latest backup actually restores
docker compose exec backup-agent mongopit verify

The verify command is the one I recommend running on a schedule and not just once. It restores your latest backup into a throwaway container, checks the data is really there, and cleans up after itself. That is how you find out a backup is broken on a calm day rather than during a real incident.

Trying the recovery drill

The most satisfying test was the drop recovery drill. Seed some documents, take a full backup, add a few more documents, then drop the collection on purpose. Run inspect to find the drop timestamp. Run restore with that timestamp. Then count the documents. Every single one is back, and the drop is gone, as if it never happened.

The first time that worked exactly as planned, it felt like undoing a mistake in real life. That is the feeling I was chasing when I started.

Closing thoughts

The interesting part of this project was not the code. It was realizing that MongoDB already keeps a complete recording of every change, and that the only thing standing between you and time travel is turning on replication and capturing that recording before it rolls away.

If you run MongoDB and you are relying on nightly snapshots alone, I would gently suggest looking into point-in-time recovery. The day you need it, you will be very glad it is there.

The tool is open source and free to use. If you want to try it, star it, or open an issue, it lives here:

https://github.com/takiuddinahmed/mongopit

You can find more of my work and writing on my website: https://takiuddin.me

Keep Cursor IDE Updated Automatically on Linux with cursor-updater

Takiuddin Ahmed — Wed, 17 Dec 2025 22:17:59 +0000

If you use Cursor IDE on Linux, you’ve probably noticed that updates aren’t exactly smooth. Cursor ships as an AppImage, which means updates usually involve downloading a new file and replacing the old one manually.

I built cursor-updater, a small, reliable Linux updater that keeps Cursor up to date automatically using Cursor’s official download API.

This post explains why it exists, how it works, and how to set it up in minutes.

The Problem

Cursor IDE works great on Linux, but updating it usually means:

Manually checking for a new version
Downloading a new AppImage
Replacing the old file
Fixing permissions
Updating symlinks

That’s fine once or twice—but annoying if you use Cursor daily and want to stay current.

The Solution

cursor-updater is a simple Bash-based updater that:

✅ Fetches the latest Cursor release via the official API
✅ Downloads and installs the AppImage automatically
✅ Creates timestamped backups before updating
✅ Manages symlinks cleanly
✅ Supports stable and insiders tracks
✅ Can run automatically using systemd timers

No GUI. No Electron wrapper. Just a tool that does one job well.

Quick Start

One-Line Install

curl -fsSL https://raw.githubusercontent.com/takiuddinahmed/cursor-updater/main/scripts/install.sh | bash

This will:

Install update-cursor to /usr/local/bin
Optionally install a systemd service + timer for auto-updates

Manual Install

If you prefer inspecting the code first:

git clone https://github.com/takiuddinahmed/cursor-updater.git
cd cursor-updater
./scripts/install.sh

Usage

Manual Update

Update to the latest stable release:

sudo update-cursor

Update to the insiders track:

sudo update-cursor insiders

What happens internally:

Detects CPU architecture (x86_64 or ARM64)
Calls Cursor’s official download API
Resolves the correct AppImage URL
Creates a timestamped backup
Installs the new AppImage to /opt/cursor/
Updates /usr/local/bin/cursor symlink

Automatic Updates (systemd)

Enable daily updates:

sudo systemctl enable --now cursor-update.timer

Check timer status:

systemctl status cursor-update.timer

View logs:

journalctl -u cursor-update.service

Want weekly updates instead?
Edit:

/etc/systemd/system/cursor-update.timer

Change:

OnCalendar=daily

to:

OnCalendar=weekly

How It Works (Simplified)

At its core, the updater:

Detects platform
Queries Cursor’s download API
Parses the JSON response
Downloads the AppImage safely
Replaces the existing installation with a backup

Core logic excerpt:

ARCH="$(uname -m)"
case "$ARCH" in
  x86_64) PLATFORM="linux-x64" ;;
  aarch64|arm64) PLATFORM="linux-arm64" ;;
esac

API_URL="https://www.cursor.com/api/download?platform=${PLATFORM}&releaseTrack=${TRACK}"
JSON="$(curl -fsSL --retry 5 "$API_URL")"

DOWNLOAD_URL="$(parse_json "$JSON")"
curl -fL -o "$TMP_APP" "$DOWNLOAD_URL"

JSON Parsing Note

Uses python3 if available (recommended)
Falls back to sed/grep for minimal systems
Includes validation so empty or invalid API responses fail safely

Features

Zero config after install
Automatic backups with timestamps
Stable & insiders support
x86_64 + ARM64 support
systemd timer integration
Clear error messages and retries
Minimal dependencies (curl, optional python3)

File Locations

Updater: /usr/local/bin/update-cursor
AppImage: /opt/cursor/cursor.AppImage
Symlink: /usr/local/bin/cursor
systemd units: /etc/systemd/system/cursor-update.{service,timer}

Uninstall

./scripts/uninstall.sh

This removes the updater and optionally disables the timer.

Why I Built This

I use Cursor daily on Arch Linux. Manually updating an AppImage every few weeks breaks flow—and eventually gets skipped.

I wanted something:

predictable
transparent
easy to audit
friendly to Linux conventions

So I built cursor-updater. Nothing fancy. Just reliable.

Contributing

Issues, pull requests, and ideas are welcome:
👉 https://github.com/takiuddinahmed/cursor-updater

Contact

Github: https://github.com/takiuddinahmed
Website: https://takiuddin.me
Linkedin: https://www.linkedin.com/in/takiuddin-ahmed-871607b5

Final Thoughts

If you want Cursor updates to behave more like a package manager—without waiting for official distro support—this tool does exactly that.

Install it once. Forget about updates.

UUIDv7 Benefits Over UUIDv4: Why and When to Use It

Takiuddin Ahmed — Wed, 27 Aug 2025 19:44:43 +0000

Introduction

If you’ve ever used UUIDv4 as your default unique ID, you know it’s easy and collision-resistant—but it scatters records randomly. Enter UUIDv7, a new standard offering time‑based ordering + randomness. In this post, we’ll walk you through why UUIDv7 can be a better default going forward—and when to stick with UUIDv4.

Primary keyword: UUIDv7 benefits

1. Setup

First, let's quickly verify environment support (Python 3.12+):

python3 --version
# Python 3.12 or higher required

Now generate UUIDs:

import uuid

# Generate UUIDv4 (random)
uuid4_id = uuid.uuid4()
print("UUIDv4:", uuid4_id)

# Generate UUIDv7 (time-ordered + random)
uuid7_id = uuid.uuid7()
print("UUIDv7:", uuid7_id)

# Show ordering benefit
print("\nGenerating multiple UUIDv7 values...")
for _ in range(5):
    print(uuid.uuid7())

Expected Output

(Your actual values will differ, but you’ll notice the UUIDv7 values are lexically ordered as time increases.)

UUIDv4: 3aaf40da-b143-48b4-9513-7827e95eea58
UUIDv7: 018f3de7-36d6-7b64-88fc-99d9f4d26a6d

Generating multiple UUIDv7 values...
018f3de7-36d6-7b64-88fc-99d9f4d26a6d
018f3de7-36d6-7b65-8fb4-62c4c4e7c5e9
018f3de7-36d6-7b66-8106-c8b35b9c9d3d
018f3de7-36d6-7b67-80e5-20d6c7b2a33c
018f3de7-36d6-7b68-8e1c-55882f2dbb6c

You’ll get two 36‑character strings. UUIDv7 includes a timestamp prefix so that new UUIDs are lexically greater than older ones. UUIDv4 is purely random.

2. Core Walkthrough: Why UUIDv7 Outperforms UUIDv4

2.1 Time-Sortable & Index-Friendly

UUIDv4 is random, so indexes fragment; databases suffer more page splits, cache misses, and slower writes.
UUIDv7 embeds a timestamp in the most significant bits, making generated values ascending, which aids index locality and write performance.

2.2 Better Cache & I/O Efficiency

Sequential IDs like UUIDv7 boost cache hits and reduce disk writes in MySQL, Postgres, and even NoSQL stores.
Experiments show significant reductions in I/O write volume using UUIDv7 over UUIDv4 in MySQL's InnoDB.

2.3 Privacy & Uniqueness

Unlike UUIDv1, UUIDv7 avoids embedding MAC addresses, preserving privacy.
Timestamp + randomness ensures global uniqueness with no coordination across systems required.

2.4 Modern, Balanced Design

UUIDv7 fixes known shortcomings in earlier UUID versions—removing v1’s privacy risk, v4’s sort issues, and v6’s complexity.

3. When Not to Use UUIDv7

3.1 Timestamp Leakage

Anyone with access to IDs can infer approximate creation times. This can be problematic for privacy-sensitive data.

3.2 Clock Dependency

UUIDv7 relies on system time. If the clock is skewed, duplicate or out‑of‑order IDs can happen. Ensure reliable clock sync or fallback logic.

3.3 Adoption & Library Support

UUIDv7 is relatively new. Many languages or frameworks still lack built-in generators—may require third‑party libraries.

3.4 Still Larger Than Auto-Incr

UUIDs (v4 or v7) take 16 bytes—more than 4–8‑byte integers. For extreme small-scale use, auto-increments may remain more efficient.

4. Where to Use Each

Use Case	Recommended Version	Reason
High-write DB (primary keys)	UUIDv7	Reduces index fragmentation, improves write/read performance
Logs, audit trails, event streams	UUIDv7	Chronological order naturally encoded in ID
Distributed systems needing order	UUIDv7	Unique & sortable across nodes without coordination
Security-critical randomness	UUIDv4	Fully unpredictable, no time leakage
Legacy frameworks or tools	UUIDv4	Broad support and simple fallback
Compact, human‑friendly IDs	Alternatives like ULID/K-Sortable IDs	UUIDv7 is still 36 chars, not shortest or prettiest

5. Trade-offs

Predictability vs. Performance
- UUIDv7 trades some entropy predictability for database efficiency.
Timestamp Exposure
- You expose creation time. If that violates data policies, UUIDv4 is safer.
Adoption Risk
- UUIDv7’s ecosystem isn’t as mature. Be prepared to vend libraries or polyfill.

6. FAQ

Q: Does UUIDv7 reduce collisions more than UUIDv4?

Not really—both are globally collision-resistant. UUIDv7 adds timestamp but its randomness portion still ensures uniqueness.

Q: Will every DB show big performance gains with UUIDv7?

MySQL and write-heavy systems benefit most. PostgreSQL sees gains but they can be modest depending on indexing strategy.

Q: Can I rely on millisecond resolution?

UUIDv7 spec defines millisecond granularity. Collisions are unlikely unless generating many IDs in the same millisecond.

Q: How do I handle backwards compatibility with UUIDv4?

You can transition gradually. Both types are 16-byte UUIDs, but sorting and indexing behavior will vary. Monitor performance and handle parsing correctly.

Next Steps

Try switching a small table’s primary key to UUIDv7 and measure insert latency, index size, and query speed.
Explore alternatives like ULID, KSUID, and Snowflake IDs for different trade‑offs.

That’s your quick start guide to choosing between UUIDv7 and UUIDv4. Choose wisely and happy coding!

What the 2025 Stack Overflow Survey Tells Us About AI Developer Tools

Takiuddin Ahmed — Wed, 30 Jul 2025 08:34:36 +0000

The 2025 Stack Overflow Developer Survey offers a window into how developers really feel about AI. Adoption of AI tools is booming, yet many coders remain cautious about trust, complexity and the parts of the workflow where AI is invited. This post pulls together the key points from the survey’s AI → Developer Tools section.

AI tools are everywhere—but trust is low

The survey shows that almost everyone is using or at least planning to use AI in their work. About four out of five respondents said they use or plan to use AI tools, and more than half of professional developers use AI every day. Early‑career developers (those with 1–5 years of experience) are the most enthusiastic—over half of them reach for AI tools daily.
Despite the rapid adoption, positive feelings toward AI have cooled. This year only about 60 percent of respondents described their sentiment toward AI tools as favorable or very favorable. That’s down from over 70 percent in 2023 and 2024. Developers also don’t blindly trust AI’s output. Only about three percent of respondents said they “highly trust” the accuracy of AI tools, while nearly half expressed some level of distrust. Seasoned developers are the most skeptical; they reported the lowest rate of high trust and the highest rate of high distrust.

AI handles research and documentation better than complex tasks

Last year 35 percent of professional developers said AI struggled with complex tasks. This year that number has dropped slightly to 29 percent, but very few people believe AI truly excels at complexity. Only around four percent think AI tools handle complex coding tasks very well. Many respondents said AI is “good but not great,” and a significant portion said AI is outright bad or very poor at handling complex work. In other words, AI still isn’t ready to own mission‑critical or high‑risk tasks without human oversight.

Where developers are using AI today

When asked which parts of the workflow they use AI for, developers pointed to research, learning and documentation as the biggest areas. Here’s where AI shows up most often:

Searching for answers – Over half of heavy AI users rely on it to look up information and troubleshoot issues. Partial users lean on it here as well.
Generating content or synthetic data – AI is popular for creating content like sample datasets or boilerplate text. About one‑third of heavy users and one‑third of partial users do this.
Learning new concepts and technologies – Many respondents turn to AI to understand unfamiliar languages, frameworks or techniques.
Documenting code and creating documentation – Around one‑third use AI to help write comments and documentation for projects.
Understanding a codebase and debugging – Some developers use AI to explore existing code or assist with debugging, although this is more common among partial users than heavy users.
Writing and testing code – Only a small share of heavy users say they mostly write code with AI, but a much larger share use it to write or test code partially.

What the future looks like

Developers were also asked about their plans over the next three to five years. Many said they plan to partially use AI for learning about a codebase, testing and writing code. Roughly a quarter are considering AI for predictive analytics, project planning and even deployment or monitoring. A smaller group plans to mostly use AI for generating content and documentation.
However, there are still areas where developers want to keep AI at arm’s length. The survey notes that people show the most resistance to using AI for high‑responsibility tasks like deployment, monitoring and project planning. More than two‑thirds of respondents do not plan to use AI for project planning, and three‑quarters don’t want AI handling deployment or monitoring.

Satisfaction depends on how you use AI

Interestingly, satisfaction with AI tools correlates with how much you use them. Those who currently use AI for most of their tasks tend to be quite satisfied. They report using AI frequently for searching and learning. People who say they plan to rely heavily on AI in the future are a little less satisfied with the tools available today, which suggests that expectations are high and current solutions haven’t fully met them yet.

Top frustrations

AI isn’t perfect, and the survey highlights several pain points. The biggest frustration, cited by about two‑thirds of developers, is getting answers or code that are “almost right, but not quite.” This leads straight into the second‑biggest issue: debugging AI‑generated code takes longer than doing it yourself. Other annoyances include not using AI regularly enough to build trust, feeling less confident in one’s own problem‑solving and having trouble understanding how AI‑generated code works. Only a tiny minority said they haven’t encountered any problems.

People still matter

Even if AI becomes capable of writing and testing most of our code, developers are clear about one thing: they still want other humans in the loop. When asked about a future where AI handles most coding tasks, three‑quarters of respondents said they would still seek human help when they don’t trust AI’s answers. Many also cited ethical or security concerns, a desire to fully understand or learn best practices, being stuck on a problem, or needing to fix complex or unfamiliar code. Only about four percent imagine they won’t need help from people at all.

“Vibe coding” is niche

The survey also asked about “vibe coding,” which refers to generating software entirely from natural‑language prompts. The answer? Most developers aren’t doing it. About 72 percent said vibe coding is not part of their professional workflow, and only around 12 percent said they do it. A few respondents have tried it or use it somewhat, but the overwhelming majority either avoid it or dismiss it.

Final thoughts

The 2025 Stack Overflow survey paints a nuanced picture of AI in software development. On the one hand, AI tools are becoming as common as IDEs or version control: they help developers find answers, learn new things and take care of repetitive documentation tasks. On the other hand, trust and satisfaction lag behind adoption. Developers remain skeptical about the accuracy of AI output, worry about its ability to handle complex tasks and are reluctant to let AI take over high‑risk responsibilities like deployment and project planning.
Perhaps the most important takeaway is that people still matter. No matter how sophisticated our tools get, developers plan to lean on each other for advice, sanity‑checks and ethical guidance. AI can make us faster and more efficient, but it hasn’t replaced the need for human judgment and collaboration. That’s a reassuring conclusion for anyone worried that robots are about to code us out of a job.

If you enjoyed this write‑up, you can find more of my work on my personal site: takiuddin.me.

DEV Community: Takiuddin Ahmed

A backup you haven't restored isn't a backup

The constraint nobody mentions: Community has no $backupCursor

We had already built one of these. We didn't use it.

What actually runs

One bucket, two prefixes, one guard

Seven days of snapshots, two days of moments

The dead man's switch

Two traps in the restore path

Four things that broke

Why 517 MB of database is a 75 MB backup

What we haven't solved

Design for the failure you'll actually have

Nightly backups aren’t enough when someone drops the wrong MongoDB collection. I built an open-source PITR system using oplog replay, Docker, and Google Drive - so you can restore to the second before disaster. Feedback welcome!

How I Built a MongoDB Backup System That Can Undo an Accidental Drop

How I Built a MongoDB Backup System That Can Undo an Accidental Drop

The core problem

The one fact that changes everything

How the recovery actually works

Why replaying the same data twice is safe

Where the backups go

A few things I learned building it

The whole thing runs in Docker

How to actually use it

Trying the recovery drill

Closing thoughts

Keep Cursor IDE Updated Automatically on Linux with cursor-updater

The Problem

The Solution

Quick Start

One-Line Install

Manual Install

Usage

Manual Update

Automatic Updates (systemd)

How It Works (Simplified)

JSON Parsing Note

Features

File Locations

Uninstall

Why I Built This

Contributing

Contact

Final Thoughts

UUIDv7 Benefits Over UUIDv4: Why and When to Use It

Introduction

1. Setup

Expected Output

2. Core Walkthrough: Why UUIDv7 Outperforms UUIDv4

2.1 Time-Sortable & Index-Friendly

2.2 Better Cache & I/O Efficiency

2.3 Privacy & Uniqueness

2.4 Modern, Balanced Design

3. When Not to Use UUIDv7

3.1 Timestamp Leakage

3.2 Clock Dependency

3.3 Adoption & Library Support

3.4 Still Larger Than Auto-Incr

4. Where to Use Each

5. Trade-offs

6. FAQ

Next Steps

What the 2025 Stack Overflow Survey Tells Us About AI Developer Tools

AI tools are everywhere—but trust is low

AI handles research and documentation better than complex tasks

Where developers are using AI today

What the future looks like

Satisfaction depends on how you use AI

Top frustrations

People still matter

“Vibe coding” is niche

Final thoughts

The constraint nobody mentions: Community has no `$backupCursor`