Flow
Save, restore, put back
1Save
Before the import, copy each top admin's key account fields and all of their roles.
2Import
The backup replaces the accounts and roles with its older versions.
3Put the account back
Update it if it exists; create it only if it has a login, a login hash and a password.
4Put the roles back
Write each saved role again; nothing is ever removed.
5Report
Print the counts; warn only if nothing at all was put back.
When I restore a backup of my staff-scheduling app, the accounts go back to how they were when the backup was made. That includes my own account, the one running the restore. If I'm newer than the backup, or my password or role changed since, I can end up locked out of my own app.
The agent tried to fix this twice in the restore script, on the same day it was working on the print schedule and on switching logins from email to usernames. Both restore changes were labeled as print schedule work. They weren't. I only found them by reading the changes.
Swing one saved the password
The first try saved each top admin's password before the import and wrote it back after. It found the account by its id number, or by a hashed copy of the login.
That only works if I'm already in the backup. If I'm not, there's no account to write to, and all I get is a warning. It also misses roles. In this app, being an admin is stored in separate role tables, not on the account. A password with no roles behind it gets me in the door and nowhere else.
Swing two saved the whole account
The second try saves the important parts of each top admin's account plus all of their roles. After the import, it puts each account back one at a time. If the account exists, it updates it. If not, it creates it, but only if it has a login, the hashed copy of the login and a password. Then it writes the roles back. If one account fails, only that account is undone, and the rest carry on.
Then the logins got renamed
Later the same day the username change landed, and the restore script was updated to know both the old and the new login column names. From reading the code, I think a restore from a backup older than the rename could still drop the login and skip re-creating a missing account. I haven't tested it.
What the second try still misses
Accounts are matched by id. If the backup gave my id to someone else, their account gets overwritten with mine. Roles are only added back, never removed. And the final warning only appears when nothing at all was restored, so if one admin out of several fails, the only sign is a slightly smaller count and a line in the server log.