We have a really old version of RT 2.0.5 which was installed by a Perl developer who customised the implementation for our needs. He has since left us and I am now stuck with an old hardware server which is failing and we have no way of migrating the data to a new server. Our users still need access to tickets and information on the server so we have to find a way to rescue the data.
I am very concerned because the hardware is failing so running an upgrade process would be dangerous. What advice do you guys have for me? How would you approach this issue?
I’d get a new server hardware (or VM) spun up and copy the database across first, so that you at least have a safe(r) copy of that. Then on a copy of the database on the new machine try installing newer versions of RT and running the upgrade process on the copy of your existing database. That way you’re not touching the old production version until the final cut over to the new server. Of course that does rely on “failing” not meaning “the hard drive has died”. If it has and you don’t have backups then you’re into the (potentially expensive) world of specialist data recovery.
An alternative if you can copy the database and you’re not confident with Perl, web servers, etc is to contact Best Practical to host and migrate it for you (as a paid service). They may also be able to advise on the local customisations you’d had made (again as paid consultancy).
Fortunately, we stopped the business from creating tickets on the old server when we installed RT4.4.4 in 2019 and created new Queues to replace those on the old one. We have a known good backup of the Database DD 2023/08/24 so we could possibly copy that one and try using it. All we need is for users to have easy access to the information in old tickets. Unfortunately, one of our client SLAs require access to data from inception instead of a fixed retention period as is normal in most cases. So, we must enable this access for the next several years or face the consequences.
Thanks for the advice, I will run this past the team.
Ah, so this is effectively a “read only” archive? In which case I’d probably try to just bring the whole lot (database, RT 2 code base and whatever local modifications your Perl chap made) onto a new server and see if it will run as is as a standalone archive system.
The biggest issue I face now is that since the DB backup on 2023/08/24, business really dragged their feet on making a decision and the hardware has just gotten worse and worse. We are now in a situation where any operations on this Server are very risky. So, I don’t know if we can even follow your advice. However, I will have a session with the dev guys and see what we can come up with. Thanks again!
we have had some issues like you. We transfered every single server to VM as it is and this way just kicked the old hardware. It seems you missed this point and the hardware is tha bad you think it won’t wor for the whole process of virtualisation.
We did the virtualisation as “desaster recovery procedure” from the machines backup but it seems you have just backed up the database, right? This is why you ask for the source.
Thanks so much for the comments and feedback guys.
I am meeting with the technical team tomorrow and we may have follow up questions. Will let you know how it goes.
It sounds like the RT install is running but not being accessed actively, correct? I would probably risk making a backup of the RT file structure and of the database. This problem is not going to get better and like other’s suggested, once you have the database and any (potential) local customizations such as Callbacks, you can bring up a “new” RT 2 server on another system or VM.
Thanks for the feedback. This is essentially what we’re trying to do now. I will keep you updated. @GreenJimll@rubberduck@miturria thanks for all the advice, I honestly didn’t expect to get help with such an old version.
