Consistency at the filesystem level
Picture what happens when you snapshot a disk while the application is writing to it. A file’s data blocks may already be on disk while the filesystem metadata (the structures that describe what lives where, like the superblock) still says something else. Restore that snapshot and you get a filesystem that disagrees with itself. Repair tools can sometimes fix it, and sometimes they can’t. Linux has a utility for this called fsfreeze. It flushes all in-flight IO to disk and blocks any new writes until the filesystem is thawed. While it’s frozen, you can copy the filesystem and know the copy is valid: it will mount, and it will restore, every time. On Upsun, consistent backups freeze every filesystem this way before the snapshot is taken. You never have to think about it.Consistency between services
Freezing 1 filesystem stops being enough the moment your application is more than a static website. Add a database next to your app and a second consistency problem appears, at a higher level this time. Take the most common example: file uploads. A user uploads an image, your application writes the file to disk, then stores its path in the database. That’s 2 writes, on 2 services, a few milliseconds apart. Now a backup runs in between. The database snapshot has the row with the path. The filesystem snapshot doesn’t have the file yet. Each snapshot is valid on its own, and together they describe an application state that never existed. Restore them and your database points at files that aren’t there.How a consistent backup works on Upsun
When you click the backup button in the Console (or runupsun backup:create), here is what happens by default:
- Incoming requests are held at the edge. They’re not dropped, they wait.
- Every service pauses its own work. The database, for example, locks its tables so no transaction is left mid-flight.
- Once all services report they’re paused, every filesystem is frozen.
- Snapshots are taken across all containers, capturing the same moment in time.
- Everything thaws, unlocks, and the held requests are released.
Live backups: zero disruption, weaker guarantees
That pause is why live backups exist. A live backup skips the coordination entirely: no held requests, no locked tables, no frozen filesystems. Snapshots are taken on the fly while the application keeps serving traffic. The impact on your live site is zero. The trade-off is weaker guarantees. At the filesystem level you’re still fine in practice: the snapshot is atomic at the block level, restoring it is like booting a machine after a power loss, and the filesystem journal replays whatever was in flight. Between services though, the guarantee goes away. There’s a chance (not a certainty, a chance) that a live backup captures a state like the upload example above, and restores with some data out of sync. Automated backups on Upsun are always live. The default policy takes 1 backup per day on production, and you can raise that to several per day. Take 4 live backups a day and one of them might occasionally catch your application mid-write. We think that’s the right default: a scheduled backup shouldn’t pause your production site 4 times a day. Engineering is trade-offs, and this one is explicit. The default optimizes for zero disruption. When you want the stronger guarantee, manual backups are consistent by default. You can also take a manual live backup with the--live flag, though it’s hard to find a reason to prefer it over the scheduled ones.