Moving the hard drive to another server?

Hello, I’m changing hardware servers and keeping the hard drive to move to the new server. I know It’s linux and I can’t move the drive over but I was wondering If there is something that will stop it from working out of the box?

Joseph

Commercial licensing of any sort is often keyed to other parts of the machine, otherwise , no prob.

No Commercial licensing at all. It’s just a old version of freepbx. I have to move it to a rack server from a desktop server. thank you.

If there’s no commercial licensing in play then just moving the disk over should be fine. You may have to reconfigure firewall settings due to different network adapters and of course if the IP has changed any settings relating to that will need to be adjusted, but the only thing FreePBX cares about the specific hardware for is activation for commercial licensing.

Even if there is commercial licensing involved it’s not exactly rocket science to deactivate the old hardware before moving the disk if the old machine is still working. If it’s not then you may need to go through Sangoma support to clear the hardware lock but it’s still pretty easy to move an activation over to new hardware.

That said, if it is an old version that’s not able to be upgraded to current through the normal process you may be better off restoring a backup to a fresh install or even just dumping the extensions and such to bulk export files and adapting it over. I usually do that when moving more than two versions forward. Some time spent copy/pasting columns between old and new spreadsheets can result in a much cleaner setup than just upgrading an old instance.

I’m afraid to upgrade it as old as it is or Change things. It been running sense 2015.

further than any need for

https://www.baeldung.com/linux/regenerate-persistent-net-rules

your probably fine

I would clone the drive and move the duplicate to the new server.
The drivers for the new hardware will be missing so you’ll need to install those.

I do have a clone drive I keep it as a backup.

Not unless very exotic, the linux kernel is pretty comprehensive if kept up to date, kmods are loaded as they are needed

The kernel is usually not the issue, it’s drivers for NIC, NVME, SATA, USB, video, etc. that usually need to be found and installed. I’ve done it dozens (maybe hundreds) of times (testing in the lab) and it can be easy if the hardware is similar or difficult if not (like AMD->Intel), or impossible (ARM->Intel, etc). Also if the age of the two systems is not close it usually means more incompatibilities (2010 Atom->2020 Celeron).

@josephchrz - a backup is fine (that’s all I really meant).

What is the best way to clone a drive on a PBX?

dd always works but takes a while,

https://clonezilla.org/clonezilla-live.php

also but needs some RTFM’ing

Thanks. Is there any way to install Colonezilla on the Freepbx Distro? Or any other one?

You probably want to clone using a different computer.

clonezilla live is run from whatever box you boot it, so if booted from the FreePBX box (presunably with a usb thingy), then yes, you can clone locally or over the network and is the least technical way described in this post

You can add clonezilla as a bootable option to grub, but that’s not for the squeamish

If you want to do it ‘live’ look at momdorescue, or google ‘cloning using rsync’.

The kernel is usually not the issue, it’s drivers for NIC, NVME, SATA, USB, video, etc. that usually need to be found and installed.

This reads like you’re coming from a Windows perspective. Linux drivers are almost always a part of the kernel itself, in general the only time a Linux user on an x86 system is going to have to manually locate and install drivers are for GPUs using closed-source drivers (read: nVidia) and certain WiFi cards which are both unlikely to be important on a FreePBX machine.

An old enough kernel could definitely have problems on a new platform, but if you’re having to think about drivers on your FreePBX systems something is very unusual.

Obviously switching a running system from x86 to ARM or vice versa is not going to work (at least not without some serious hackery) but moving from one x86 system to another will almost always “just work” as long as the kernel is new enough for the new hardware.