I've got the following scenario:

Two K1000s both at the same version (5.5.90548). One K1000 is for production, the other is for testing.

I'd like to restore the backup from the production server to the testing server and then upgrade the testing server to 6.0.


Once the upgrade completes, am I OK to change the IP and system name of the restored (testing) server so as to confirm that everything is working OK while still using the production server in production? After confirming that the restored server is good to go, I'll take the production server down and change the IP and system name to what the production server was and begin using it in production.

Make sense? I do understand that any changes to the production server while testing the upgraded server will not be reflected in the upgraded server.

The main reason for doing this is because I have a very large device count (45K+ and growing). In the past upgrades have taken a very long time and I don't want to take the production server down for that period of time. Also, if there is an issue with the upgrade, I'll still have the production server to fall back on.

0 Comments   [ - ] Hide Comments


Please log in to comment

Answer this question or Comment on this question for clarity



Just watch when you do the restore on the test box the IP does not change to the IP that was on the production box when you made the backup.  During the upgrade choose an IP that will make sure no devices attach to the kbox, this will insure changes are not made to the database by clients.  This upgrade took about a third of the time the 5.4 to 5.5 took for us.  You can always pull the network cable from the test box when it reboots from the restore for safety

Answered 06/04/2014 by: SMal.tmcc
Red Belt

Please log in to comment

I just got done doing this exact thing last week. Ours just happened to be at the same time of a hardware refresh so I had the new one in place. When you restore the DB it will get the IP from the database restore. Our restore took 20+ hours. There's no status that anything is actually happening, you just have to wait. After about 12 hours I went through the console, and tried to get a status. I received a "cannot connect to localhost error". The good thing is that even though the new box now had the same IP, it did not take control until I powered off the old one and rebooted the new one.

I also did something similiar since we split the load of ours. We are now running multiple boxes. I restored the DB, and waited over night. After the restore was complete I logged in via the console and changed the IP/name. After a reboot it was ready to go.

I'm curious how large is your database? What is your check-in time with 40 K machines? We have over 20 K.

Answered 06/04/2014 by: dugullett
Red Belt

  • I do also agree with smal that this update did not take as long. After the update loaded to the box, and it began I just went and pulled the patch cables. It allowed the appliance to reboot without having to deal with all the check-ins.
  • Thanks everyone for the replies. I'm copying over the database today and will begin the upgrade soon after that.

    dugullett - Check in is once every 24 hours. The database is 618MB. I'm tempted to split the load between the two kboxes also. Maybe student devices on one and teacher/admin on the other. I've also thought about doing High and Middle school devices on one and Elementary on the other. I need to weigh the pros and cons of each.
    • Yeah our database is 1.7 GB, and the .tgz is 42 GB. We needed to stay with an 8 hour check-in so that's why we did the split. It's worked out great so far. I think my only issue with it is trying to remember what Kbox you are in.

Please log in to comment