Repository navigation
Replies: 2 comments
|
@Kriegbaum please see some guiding steps below: BackupWhen running an update, always ensure you have a database snapshot before you start. Move that out of your normal backup directory too, and keep multiple copies DowngradesThere is no supported "downgrade" path from a new version to an older database - as typically the database schema itself is adjusted during an update. If you go back to an older code point, your database is now out of sync - and your code doesn't know how to get it back to the original point, as the required changes are not contained in the older code. Sequential UpdatesYou should read the "breaking changes" for each of the intervening releases. Below are the major releases between
Error MessagesDo you have any error logs you can provide from your |
|
Yeah, unfortunately as I mentioned I didn't take the time to do thorough notes as I went through this so I don't have are any error logs. I was able to successfully restore my cold storage backup and nothing of value was lost because I haven't been doing any ordering or building in the last couple weeks. I'm ready to give this another shot and I'll take good notes this time and review the information you posted above (it is very helpful to see this all in the same place, thank you for the thorough response). I'll report back here with successes or failures. I saw in the |
Uh oh!
There was an error while loading. Please reload this page.
Hallo Everyone,
I come to you today asking for a bit of advice. I have an inventree install that is currently sitting at
0.17.9and has been for quite some time problem-free. I probably should have been updating more often but so it goes.There is a feature in
1.2.0that I would very much like to use so I went about trying to get there last night. Due to some difficulties in my last upgrade process, I decided to take a more cautious approach and go0.17.9->0.17.14->1.0.0->1.1.12->1.2.0->1.2.3and check up on the database at every step of the wayIn retrospect I believe this was a bad idea, as the number of steps in this process multiplied my opportunities for mistakes. For each step I updated the Inventree tag in the
.envfile and did the followingI believe somewhere around
1.0.0the server became unreachable on my network and i was able to repair this with some changes to site url and some x forward related arguments in the env file. I access this server by a hostname and port number on LAN and I haven't seen any examples of someone else using this setup, I think there is something not quite right about the way I have executed it, as this exact thing has caused me some issues in the pastAt
1.1.12->1.2.0upgrade, I followed this guide: https://inventree.org/blog/2026/02/12/db-updateAnd after that the site was unreachable again and I couldn't figure out how to fix it so I rolled back to
1.1.12and noticed that the parameters section of the web interface was broken with database errors being thrown. I'm not sure if this happened at an upgrade step or if it was rolling back from1.2.0that did it. From there I decided to restore my0.17.9DB and try again later, but all the restore options I tried also failed and I think completely botched the database. I have a json DB agnostic backup, a standard backup created from0.17.9(attempted to restore to same version) and the migration.sqlfile generated at the1.1.12->1.2.0step. I can't get any of these to give me a working database. At this point I'm going to be pulling a cold storage backup from last week and attempt again with even more caution. Like a total rookie I did not turn off my hourly backup service before starting and the local redundant copy was replaced with my botched database. Live and learn.This post is not me asking for help repairing the current situation or trying to figure out where I went wrong. I did a lot of different things and I think after my first mistake I just started digging a deeper hole. My gut tells me I forgot to do a
docker compose downat some point and started operating on a still-running container but I'm not sure.What I would like advice on is the best strategy for a reattempt. I am currently running this with a
docker-compose. My most successful backup/restore in the past came from zipping up the entire docker volume and placing it back in my docker-compose root, which is how I'm planning on carrying out the cold storage restore. Is jumping from0.17.9straight to1.1.12possible? I figure there is less room for mistakes if I run the update process less timesAny guidance would be appreciated. I am surprised with how quickly I got my install into a state I could not figure out how to recover from and I feel like I'm in over my head here
All reactions