Anyway, I still had the DB dumps from the previous upgrade and the installer and after figuring out I needed to turn the clock back a year for the upgrade to take (Code42 won’t let you upgrade if your license has expired), it was all good. Why didn’t I take a snapshot from the last time? Well, because I’m a noob.
Why didn’t I just copy the production VMs across? They’re simply too big. This meant that before even testing an upgrade, I had to get them back up to the version in prod. But it turns out I had decided last time to wipe clean these VMs and so my CP Enterprise directories for both VMs stood bare with nary an installation to be found. I had expected that since the last upgrade they would be at the current production version so I could just restore the prod databases to them an get on. I have 2 test VMs setup as Master and Storage servers for CP Enterprise mirroring what I have in production (except for the backup data). And sometimes these upgrades don’t go as smoothly as expected. Code42 recommends you test the upgrades and for good reason. Upgrades, however, are a bit of a tricky mess. It’s surprisingly affordable and robust which is why I recommend it to my clients. It should have been straightforward but as usual I must have done a little too much clean up from the last time.įor my backups I’m using Code42’s Crashplan Enterprise platform. So while I was updating my Mac Pro VM host, I decided to test the upgrades for my backup environment.
0 kommentar(er)
