-
Notifications
You must be signed in to change notification settings - Fork 687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore from backup fails #3878
Comments
Replicated without the |
FWIW, this was not reproducible on a fresh 0.10.0-rc2 install on 2014 Mac Minis. |
Root problem is that the backup is stamped at the wrong migration version:
The revision |
I cannot reproduce this on
In every case when I checked the alembic revision, it was |
Wait hold up. Just realized that the zip you provided was the zipped backup pre revision that the * this line in db_backup="/var/lib/securedrop/backups/$(date +%Y-%m-%d-%H-%M-%S)-db.sqlite" |
Ok wait never mind again. That just got grabbed by the backup script because it was in I'm pretty sure this bit in if ! echo "$sqlite_tables" | grep -q journalists; then
log_the_shit UPGRADE HEAD
# This is a fresh install, run the full migrations.
alembic upgrade head
else
log_the_shit STAMP
# This is an old install, so mark that the schema is up to date
# as of the version of migration 15ac9509fc68_init.py when we first
# started version controlling the database.
alembic stamp 15ac9509fc68
fi But I'm not sure how the check is failing. I don't like the amount of the really tricky logic in |
Also not reproducible in Mac Mini upgrade testing, either with a 0.9.1 -> 0.10.0 backup or a 0.10.0 -> 0.10.0 backup. |
@heartsucker you mentioned "flakiness" in sprint planning, can you expand on exactly which logic you think is flaky? Is it this line? (flakiness there will cause us to enter the code you point out in I just want to make sure we agree that this logic is solid prior to closing this issue even though we're having trouble reproducing. Obviously, any flakiness in database migrations is very high priority to resolve. |
Both lines 38 and 41 would have to fail for very bad things to happen. I used flake because we got an error once somehow, but can't reproduce (the initial problem that cause this ticket to be opened). I don't think those lines are going to break in any non-totally-borked-OS situations, but I guess I like ironclad. monadic error handling and not this whole bash Which is to say. I think this is robust enough to warrant closing the ticket. If I thought that above I just hate this about
The error from |
great, agreed @heartsucker. And since multiple testers can't reproduce and looking at a long-running (since 0.8) prod test instance (@emkll just did this) confirms the database is at the expected revision, I'm closing this. |
Description
During testing of 0.10.0~rc2 on prod VMs, I created a server backup, ran
./manage.py reset
on the app server to nuke the database, and tried to restore from the backup. This failed with the error text below:Steps to Reproduce
./manage.py reset
on the app serverEnvironment
Candidate version: 0.10.0~rc2
Tails version: 3.9.1
Instance hardware: prod VMs
Expected Behavior
Server config and DB are restored without error
Actual Behavior
Restore fails with the errors above
Comments
Attached copy of sqlite db backup referenced in the first error message.
2018-10-16-03-20-48-db.sqlite.zip
It looks like it's related to the uuid column:
The text was updated successfully, but these errors were encountered: