Stop lying to your backup scripts about file consistency

Technical Briefing | 9/12/2026

We have all been there. You write a nice loop that tars up a web directory, pushes it to S3, and emails you a success message. It works perfectly for months. Then you try to restore a database dump that was in that folder, and the file is complete garbage. The application was writing to the journal while your backup script was reading it, and now you have a corrupt mess.

Why standard reads are a gamble

When you run rsync or tar against a live mount point, you are asking the filesystem for a slice of reality that is constantly shifting. Unless you are using atomic operations or a frozen snapshot, you are technically performing a partial copy of an evolving file. You might get lucky, but luck is not a disaster recovery strategy. If you rely on the filesystem metadata to decide what changed, you are already behind.

lvcreate -L 5G -s -n backup_snap /dev/mapper/vg0-data
mount /dev/mapper/vg0-backup_snap /mnt/backup_source
tar -cf /backups/data_$(date +%F).tar /mnt/backup_source
umount /mnt/backup_source
lvremove -f /dev/mapper/vg0-backup_snap

The snapshot workflow you actually need

• Use LVM or ZFS snapshots to create a point-in-time view that does not move while the copy runs.
• Flush application buffers before snapping if you are running anything involving a database or message queue.
• Verify your checksums after the copy, otherwise you are just backing up corruption.

Stop treating live production data as a static repository for your cron jobs. If your script does not know how to handle the difference between a file currently being written to and a stable archive, it is just waiting for the day it creates a resume-generating event. Start automating the snapshot process instead of just pointing a mirror tool at your active mount points.