We support a few instances of freePBX. We upgraded one instance to version FreePBX SNG7-PBX-64bit releases and I have decided not to upgrade some of the other instances.
Well, outside of 2 maybe 3 reboots the actual system does not stop functioning. I’ve run this update script numerous times on systems and during the entire process the only time they didn’t have a working PBX was when it was rebooted.
Overall the downtime will be about 5-10 minutes and not at once. If you’re running a system that has no room for maintenance windows that allow for that kind of downtime for updates then you are in a world of hurt.
Actually, no it is not. Based on the original post the OP did the update on a single system and decided not to do the updates on the rest. However, they already started the update process on the other systems by installing the RPM.
I then asked why they decided to not do the updates on the other systems. That’s when the OP said they can’t afford to take it down as it is a 24x7 PBX (as most are). So my statement about having a system in production that can’t be taken down for 5-10 minutes in a single maintenance window will lead to a world of hurt still stands. As that means no updates can be run as nothing can be stopped/restarted to interrupt service.
As I pointed out, there are like three reboots in this entire process and after each reboot the PBX still runs as normal. Phones can still register, outgoing calls can still be made, incoming calls can still be accepted. Only the reboots impact service so even giving a 10 minute window is generous as most system should reboot in minutes.
There has to be a point during a 24 hour period where this machine can afford to reboot for this process. If there isn’t because the call flow is so heavy then the backup should be used during this time.
I’m going to go with the fact there is nothing in place to take over if this machine takes a crap.