generated from jric11/baseProject
69 lines
3.0 KiB
Markdown
69 lines
3.0 KiB
Markdown
|
# Database backup, migration and verification
|
||
|
|
|
||
|
|
Completed October 18, 2026 against the configured **development** database:
|
||
|
|
`192.168.1.190/huntingclubroster` (MariaDB 10.5.29).
|
||
|
|
|
||
|
|
## Backup
|
||
|
|
|
||
|
|
The complete SQL backup includes tables, views, triggers, routines and events:
|
||
|
|
|
||
|
|
`.tools/backups/20261018-190815/huntingclubroster.sql`
|
||
|
|
|
||
|
|
It is 34,198 bytes. SHA-256:
|
||
|
|
|
||
|
|
`0cf92f6c5e05433a50bf7f8a8288e39e68893ad82dff679f2d57ea1317d358d9`
|
||
|
|
|
||
|
|
The backup completion marker and checksum were verified. It was restored into
|
||
|
|
an isolated local MariaDB server, and row counts matched for all 10 original
|
||
|
|
tables. The authentication migration passed against the restored copy before
|
||
|
|
being applied to the configured database. The restore copy was then removed
|
||
|
|
and the temporary database server shut down. The original backup is retained.
|
||
|
|
|
||
|
|
The server does not support TLS. The user explicitly approved an unencrypted
|
||
|
|
database connection for the backup, migration and verification. SMTP transport
|
||
|
|
remained encrypted with certificate verification enabled.
|
||
|
|
|
||
|
|
## Migration
|
||
|
|
|
||
|
|
The migration added `users.user_auth_version`, `password_resets`, and
|
||
|
|
`auth_attempts`, ensured transactional user storage, and refreshed `view_users`.
|
||
|
|
Existing user data (including the password hash) and all original table row
|
||
|
|
counts were confirmed unchanged immediately after migration.
|
||
|
|
|
||
|
|
## Verification against the migrated database
|
||
|
|
|
||
|
|
Eleven checks passed using temporary account data:
|
||
|
|
|
||
|
|
1. Signup page loaded.
|
||
|
|
2. Signup created a regular user account.
|
||
|
|
3. An incorrect password was rejected.
|
||
|
|
4. The new account could log in.
|
||
|
|
5. Logout succeeded.
|
||
|
|
6. The configured SMTP provider accepted the authorized reset email over TLS.
|
||
|
|
7. The generated reset token opened the password form through the local server.
|
||
|
|
8. Resetting the temporary account password succeeded.
|
||
|
|
9. Reusing the consumed token failed.
|
||
|
|
10. The previous password failed after reset.
|
||
|
|
11. The new password could log in.
|
||
|
|
|
||
|
|
The reset request was generated by the shared authentication service and sent
|
||
|
|
through the real configured SMTP transport. Signup, login, logout, reset-token
|
||
|
|
validation, and password replacement used the actual HTTP handlers. No existing
|
||
|
|
account was used for a password reset. The temporary account, its reset tokens,
|
||
|
|
and test rate-limit records were removed; the existing account snapshot matched
|
||
|
|
after cleanup. A skipped auto-increment value from the temporary account is
|
||
|
|
expected and was not reset.
|
||
|
|
|
||
|
|
Private machine-readable manifests and results are stored beside the backup.
|
||
|
|
The backup folder and temporary verification helpers are ignored by Git.
|
||
|
|
|
||
|
|
## Public-site limitation
|
||
|
|
|
||
|
|
`https://app.myhuntingclubroster.com` did not resolve from this machine during
|
||
|
|
verification. The checks used the updated local application connected to the
|
||
|
|
configured development database. They do not prove that the public server has
|
||
|
|
the new code or that its database is this same database. DNS, deployment and
|
||
|
|
public HTTPS operation still need verification before declaring the live site
|
||
|
|
ready. SMTP acceptance was verified; receipt in the recipient's inbox was not
|
||
|
|
independently confirmed.
|