Self-Managed backups from Gentoo antsleOS to CentOS antsleOS

via Daniel's instruction I tried to upgrade my antsle to the new CentOS based edgelinux this weekend.

I tried to send all my backups to the antlse cloud, but kept getting errors, so I backed up my antlets to a self-managed usb drive (another suggestion by Daniel) and ran the upgrade (easy-peasy), only now my antsle can't find the backups of my old antlets. Daniel had said that I would find them under "Heal Antlets" but they are not there.

I researched the forum here and I found someone else had an issue where Johannes had given them an import/export antlet script.  The import-antlet script gave an error stating "bad magic number".

I researched some and found that it's likely due to file type because of the gzip compression of the backup, so I used gzip to decompress the backups and ran the script again, but got an error on the part that destroys the snapshot.  Since the backup isn't a snapshot, I decided to skip that part and run the next part of the script manually.  Since I'm using Windows antlets, I know that the domain type is KVM, so I manually typed in the virsh command.  This time the import went OK, (as in, I had the antlet listed in the antlets section of the dashboard) but the antlet wouldn't start due to a missing binary "qemu-system-x86_64" which I couldn't find.  I did however find the file name in the antlet-libvirt.xml file, so I checked and it's not in the usr/sbin/local folder, at all.

So I created a new Windows Server antlet and found "qemu-kvm" is used to run the antlets on the new system, so I tried to edit the antlet-libvirt.xml with the new binary, then tried to re-import the old antlet.

Next error was regarding "vmport", so I removed it from the XML file and re-imported the antlet.

Now the antlet "starts" but is stuck in a repair Windows OS loop and nothing I have tried will break the loop.  The Windows System Repair will only accept the local administrators password, which apparently is not the one in my password manager (actually, I think I may have disabled the account when I created the domain).  Domain Admin and Domain users are not valid users to repair a DC with.

Would like some help with this as this was my domain controller and now I'm without one until I either build a new one, or find a way to get the old one working!

Anyone else have any ideas?  I had 6 windows machines as antlets under the old system and would like to get them back, but am betting the change from qemu-systemx86_64 to qemu-kvm is what killed them.  I don't really want to have to re-create my entire domain, although it would allow me to fix some of the mistakes I made :-).

Also, has anyone successfully done this from the antsle cloud?  if so, maybe I'll downgrade back to edgelinux 0.12.1 and redo the entire process using the cloud, assuming of course that I can successfully backup all my antlets to it!

Nope, I've got several tickets in with support for trying to restore gentoo based antsle backups to the new CentOS antsle.

I was assured when I purchased the new antsle that restoring backups from the old to new and vice versa was working and easy,  and all the cool kids were doing it.  Not so.

I even upgraded my gentoo antsle to CentOS version (it did help with issues my old one was having)  but no joy in restoring ANY  version of antlet backup to the other server.  Then my new antsle cratered so it's back in the shop now (over 2 weeks now).

So I DID rebuild my production environment... on my old antsle.

I wish you better luck.

thanks @spollock for the well-wishing.  Support has told me that a fix might be made available today.  Here's to hoping!

I'm going to keep trying with the import/export script to see if I can't hack together some steps to get it working.  Someone else mentioned that creating a new antlet and then replacing the qcow2 file with the old antlet's one seemed to work, but I haven't tried it yet.  I will be trying that today.

Quote from acnicholls on June 2, 2020, 9:48 am

Someone else mentioned that creating a new antlet and then replacing the qcow2 file with the old antlet's one seemed to work, but I haven't tried it yet.  I will be trying that today.

That might work for KVM antlets that use a single file drive, however LXC antlets have a structured folder system and not just a single file.

I was able today (using the newly released antMan 3.1.0b) to get an LXC antlet to restore from a Gentoo backup to a CentOS server.  The caveat here is that its the same server. Old Antsle One that has been upgraded to CentOS.  I still cannot say if the restore works between boxes. I can say that the "Restore as Clone" function still is not functional - even to the same hardware.

I had to use the RESTORE feature so it over-wrote the newer antlet which was a simple html webserver of the same name.  It was a WordPress website and everything seems functional again.

I still cannot restore a backup if the antlet name does not exist, so the feature itself is not a TRUE backup/restore.  It is more like a snapshot that is dependent on the original being available.

Glad to hear that you got something working.  All my antlets were windows, so KVM, not LXC, and when I try to start the antlet after replacing the qcow2 file, I get into an endless system repair loop.  Likely due to so many changes in the system architecture.

for starters, the <os> entry in the antlet-libvirt.xml file contained in the backup shows machine='pc-i440fx-2.4' but on a newer antlet the same entry shows machine='pc-i440fx-rhel7.0.0'

also the <emulator> entry on the older antlet-libvirt.xml file shows /usr/sbin/local/qemu-systemx86_64 and the newer xml file shows /usr/libexec/qemu-kvm.

from what I understand (which admittedly is very little in comparison to many) this xml file is telling the virtual machine host that the OS has a different signature, and is running on a different machine.  Windows doesn't like that usually.  I'm hoping to see a comment soon from the antsle folks, but it may be days away.  In the meantime my home development lab is completely shutdown!!

finally (and here's the kicker for me) they've now (since antMan 3.1.0) introduced a 15 character limit to the antlet name.  my domain controller antlet had a longer name than that...DC1_WinServer2019 (it was actually WinServer2016 os, but I wasn't paying attention when I created it), but the new antman only allows DC1_WinServer20.  Ah well, I was wanting to change my domain's name anyway, as well as the antlet name!  Maybe it's for the best, but I think I'll go back to edgelinux 0.12.1 if I can get an installer for it, and then get all the required information off of all the machines.  The antsle folks made it sound like this was going to be a piece of cake upgrade.

At least they fixed the licensing issue with my nano!

Oh.  Yes windows servers... I haven't had to install a domain controller since 2008. I don't miss it really.  LOL.

anyway, my replacement One D arrived today. I was able to get an older (gentoo) backup of my VPN server (LXC Debian 8.5) to restore as clone! Both servers are on antMan 3.1.0b now so that may have had something to do with it.  I did have to create a new antlet with the same name before it would work though I guess its looking for the name before it restores.  So my restored antlet name was VPN2 ... and it had the old root password I was using so I guess it was a successful restore.

I wonder if you create a KVM antlet using the same name as one of the backed-up antlets (if you have one with the shortened naming convention) then try to restore or restore as clone from the backup.

I noticed the changes in the name length, but being an old DOS guy... I still mostly live in 8.3 world just by choice.

Your reference to the xml files... i believe the old gentoo box was release 2.4.  I know the CentOS 7.0 (rhel7.0 = Red Hat Enterprise Linux) they are virtually the same CentOS being the free, community developed and supported release but it lacks enterprise level support. I feel EdgeLinux is a marriage of the two.  Someone please correct me if I am mistaken.

Good luck with the rest of your issues.  I give the support guys a good 7 out of 10 most days but speed is not a strong point with them.  I'm on the east coast so the time difference is one thing... but I can usually get one response or answer to yesterdays' question. Then I wait for the next answer to todays' question... It's a vicious cycle.

haha, I started in DOS too.  Also an East coast guy myself, or at least Eastern Time Zone anyway.   I'll try one of the other servers with a shorter name, all the others are under 15 characters, I don't know why I named an antlet with such a long name.  I was trying to have the OS type as well as it's purpose and wasn't thinking of DOS, given that I had recently installed python 3.8 on something and checked the box that allowed for path names longer than 260 characters!  If the DC is the only thing I have to rebuild from scratch, I'll be very happy about that.

Since it's the only domain I've ever had i wonder if it'll be a problem to remove the current computers from the domain without having the domain controller on the network?  A problem for another day, for this evening, time to attempt re-creating the rest of my network!

@spollock

Where did you place the backup file? I tried the following

1. in a folder on /mnt/usb1
2. in the root of /mnt/usb1
3. in /antlets/_backups

I'm about to try decompressing the file in all 3 locations as well, since it's gzipped right now.  I named my new antlet SqlServer, just like the old one from the Gentoo installation, but the newer OS is not seeing this backup of the antlet.

maybe it's polling at intervals?

My backup file was in antsle's cloud, so I retrieved it from the heal antlets screen.  That puts it in /antlets/_backups ...

@spollock

does it put it there in zfs.gz format, or just .zfs?