kamal-backup 1.0: A Backup Is Only Real After You Restore It

I released kamal-backup 1.0 today. Not because the backup command works. That part worked months ago. I called it 1.0 because I used it to move Chat with Work, the application that pays my bills, to a new Hetzner instance. The old host took the backup. The new host restored it under a temporary hostname. I opened the real application, checked the real data and files, and only then moved DNS. A backup is only real after you restore it. The migration that made 1.0 The move found two bugs that a green backup log never could. First, a fresh backup accessory on the new host could start its schedule before the restore and write a perfectly valid, completely empty snapshot into the same repository. Ask for latest during the migration and you could restore that one. Second, Kamal had already run Rails’ db:prepare on the new host. PostgreSQL’s normal pg_restore --clean path could not reliably replace that prepared schema when target-only foreign keys got in the way. Drops failed, creates…