Best Practice to deploy Mondorescue on a running FreePBX Distro

Is there any (specific related) best practice to follow in creating a live image of a running FreePBX Distro system with Mondorescue?

I just posted elsewhere.
I suggest you remove any UUID use in your grub and fstab, apart from that it has worked for me flawlessy on Centos and Debian based system for years (a weekend cron job to a local and offsite location) For efficiency I would not include the dynamic data like monitor files and voicemail, IMHO they belong in a more timely rsync schedule.

I imagine it would work also on the Distribution with the caveate that restoring on anything but the original hardware will probably mean that you will need to repurchase/Re-register any of the Commercial closed source bits ( I don’t use any though)

If you image into a bootable usb disk always mounted, then even the least computer-savvy user can be talked though booting that usb-disk and restoring last weeks machine state without a truck-roll, then it is easy to fix up the machine remotely.

Also from experience and depending on your systems, prior removal of any MACADDRESS stuff from your network interfaces will also make things easier, as the device(s) will still come up as eth0 (whatever) and not be messed with by udev or whatever (this is probably the bit that will break the closed source stuff though :slight_smile: ).

So you suggest to exclude some system folders and/or stopping some services (mysqld, asterisk, amportal as examples) before launching mondorescue? if yes, what exactly?

Regarding the licensing I understand the (re)licensing requirements imposed by Schmooze Com. That will not be a problem I think (in case of rescue from a Hardware system failure I mean).

That’s an interesting option (imaging to a USB stick always mounted OR to a NFS Share, where I actually perform FreePBX Distro full backups daily).

I don’t understand this part (are you saying that rescuing an image from an Hardware - e.g the Ethernet Interface - that has a “signature” like the MAC Address will cause issues on the new Hardware, that’s OK): should I to remove any MAC Address reference eventually present from my running Hardware configuration before imaging?

It is not necessary to stop anything, but it will probably be necessary to restore the mysql tables and other “state” from the latest successful backup.

I use something like:

/usr/sbin/mondoarchive -OVi -d $LOCALBUDIR -E "/backup /var/lib/asterisk/backups /var/spool/asterisk /var/log " -s 4800m -p “hostname_date +%Y.%m.%d.%H.%M

then

/usr/bin/rsync -at --inplace --progress -e ‘ssh -q -p $SSHPORT’ $LOCALBUDIR/*.iso $BUSERVER:$BUDIR/hostname/

add anything else appropriate into the -E argument.

Mondorestore can indeed restore over the network and can make bootable usb disks or .iso that can be dd’ed into one, these images can be self contained OR NFS based, but of course a big machine will take quite a while to restore a multi-GB image over NFS My images are rarely bigger than a DVD so that is another option.

Only if the MACADDRESS changed :wink: but for a truly catholic image then remove it and it should not confuse udev if you adjust udev prior also if necessary.

It’s exactly the same thinking that is around UUID’s there is immutable hardware on physical machines yet the hardware historically is just a bus device and can have lower level definition, (perhaps not so true in a virtual machin, think about that when it comes to “hardware” keying :wink: )

Thanks Dicko! now I have sufficient material to work on…

Another caveate, I said “always mounted” perhaps I should have said “always physically plugged in” you can then mount and dismount the device as appropriate.

OK, so it’s always better to remove UUID from fstab and grub to have a system more Hardware agnostic as possible (in case of rescue from an image of it into another Hardware).

I think so, add the complications of using a multipath UUID for software raids and I think you will see my point , it is easier on my old brain to mess with /dev/md0, /dev/sda1 and the underlying /dev/sda then 84491358-292f-45bd-bdcd-96177772ff26 is it for example part of c07bc4d7-2c66-48aa-af88-acaf50e55233 or not? and when your hardware drive dies and it is now 08b454d5-927d-4edc-be7d-76d0c629c64c. I let mdadm reasonably handle the UUID’s but if you ever need to boot a broken grub system then using the UUID’s would be frustrating to say the least.