[Help]: Backup volumes before upgrade? (and upgrade procedure in general) #545
-
Controller Versionv5.13 Describe Your Issue or QuestionWhen planning an upgrade from v5.13 to v5.15.8.2, I've taken a backup of the controller configuration and data. IIRC, an upgrade could update the database schema, making it impossible to revert to the current version in case of problems. Should I also make a backup copy of the omada-data and omada-logs volumes, after stopping the container? More generally, should the steps to perform an upgrade be:
And the procedure for reverting in case of problems:
And of course, in case of total disaster:
Sorry if this is a very basic question, I'm still quite new with Docker and don't use it except for this image. Expected Behaviorn/a Steps to Reproducen/a How You're Launching the Container
Container Logs
MongoDB LogsNo response Additional ContextNo response |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
You've got the process down quite well. I don't have any significant changes to what you said, just some reminders, really: For stopping the container, just make sure you've either specified a stop timeout when starting the container or manually specify one at stop time to allow enough time to gracefully shut down the app and MongoDB. See this section of the readme for more info on that. For your steps, you don't really need to keep the previous container around; you can remove the old container before starting the new one as there is nothing unique stored inside the previous container. As long as you have the image from the previous version, you can roll back quickly. Plus if you're like me, I like the name of the container to remain the same and you'd have to rename the container but that's all just an unnecessary step, in my opinion. |
Beta Was this translation helpful? Give feedback.
You've got the process down quite well. I don't have any significant changes to what you said, just some reminders, really:
For stopping the container, just make sure you've either specified a stop timeout when starting the container or manually specify one at stop time to allow enough time to gracefully shut down the app and MongoDB. See this section of the readme for more info on that.
For your steps, you don't really need to keep the previous container around; you can remove the old container before starting the new one as there is nothing unique stored inside the previous container. As long as you have the image from the previous version, you can roll back quickly. Plus if you're like…