Omd restore fails, previous version needed

Hi

I run two checkmk sites, second is kind of a hot DR with notifications disabled. I take a backup of the prod site with omd backup and do an omd restore on the DR to keep it in sync. I recently updated both of them from 1.6.0p10 to 1.6.0p14 and then did a cleanup to get rid of p10. Now when I backup the prod site and try to restore to DR, it fails saying p10 has to be installed. But the prod site is p14 so why is it saying it needs p10? Do you really need to keep all your old versions after an update?

I would understand that my old backups might require this, but why a fresh backup taken after the update?

No only the current version is needed.

This is strange. You are sure that on your prod system only p14 is running and installed?

1 Like

I am sure.

OMD[sitename]:~$ omd version
OMD - Open Monitoring Distribution Version 1.6.0p14.cre
OMD[sitename]:~$ omd versions
1.6.0p14.cre (default)

In /check_mk/version.py it also shows p14, and I acknowledged all the werks.

I have a work around for now, I can just rsync the site folder in /opt/omd/sites

I have no real good idea what you can do. Only one test would be to create a new empty site on your productive system, make a backup from this empty site and try to restore this backup to the other server.
If there comes the same error, something on your productive system is wrong.

You could also try to check the version of the backup file like so:

root@cmkserver:~# tar -t -v --wildcards -f backup.tar.gz "*/version"
lrwxrwxrwx stest/stest       0 2020-06-18 15:54 stest/version -> ../../versions/1.6.0p12.cee.demo
-rw-r--r-- stest/stest      18 2020-06-09 16:30 stest/.version_meta/version
lrwxrwxrwx stest/stest       0 2020-06-18 15:54 stest/version -> ../../versions/1.6.0p12.cee.demo

With that output I know that backup.tar.gz contains a backup of the site stest which was running with 1.6.0p12.cee.demo. Maybe that helps.

1 Like

Hi Dirk, looks like the expected p14 in the backup

[root@server files]# tar -t -v --wildcards -f site_omd_backup.tgz “*/version”
lrwxrwxrwx site/site 0 2020-07-23 17:02 site/version → …/…/versions/1.6.0p14.cre
lrwxrwxrwx site/site 0 2020-07-23 17:02 site/version → …/…/versions/1.6.0p14.cre
-rw-r----- site/site 13 2020-07-23 17:02 site/.version_meta/version

I have verified the same issue on another environment that I built fresh with p10, created a site, upgraded to p14, took a backup and then tried to restore on a different server built in the same way and it still errors saying p10 needs to be installed. At this point I would call this a bug, is there anyway to report this or just hope its seen in the forum?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

I tried to reproduce your problem, without success. My steps:
Setting up in AWS: Ubuntu 18.04 with defaults
Installing v1.6.0p10 CEE
omd create test
Installing v1.6.0p14 CEE
omd update test
omd backup test test.tgz
Copy test.tgz to second AWS instance (with installation of first v1.6.0p10 CEE, then v1.6.0p14 CEE)
omd restore test.tgz -> successful

On the restore target host, what does ‘omd versions’ say as root?

Hi Dennis

I am running centos 8.2 I start out with

[root@apollo-test ~]# omd versions
1.6.0p17.cre (default)

I backup the site, install p18 and update the site

[root@apollo-test tmp]# omd versions
1.6.0p17.cre
1.6.0p18.cre (default)

I then do an omd clean up to get rid of p17

[root@apollo-test tmp]# omd cleanup
1.6.0p17.cre Uninstalling
1.6.0p18.cre In use (by test). Keeping this version.
[root@apollo-test tmp]# omd versions
1.6.0p18.cre (default)

Now I try to restore the backup

[root@apollo-test tmp]# omd restore test /tmp/backup.tgz
You need to have version 1.6.0p17.cre installed to be able to restore this backup.

Is this a bug with CRE if you did not experience this with CEE?

So you did a backup of p17 before updating?
Then the backup will still be a p17 backup.

1 Like

Ok, you are trying to restore to the same host, right?

Restore requires the same version (and edition) to be installed when producing the backup. Restore does not include an implicit update.

Apart from this, when you restore a site, the restored sitename should not already be in use on the host.

@Dirk
In this specific example yes, but if you see in my original post the backup was taken after an upgrade and it still said it required the previous version to be installed. If you have to keep every single version installed for backups to work, thats not ideal?

@dennis.ehmer
In this specific example I was restoring to the same host just to reproduce the error. What happens if you need to restore a backup from before your last update? does performing a site update render all historical backups obsolete?

My workaround is to manually extract the site backup and rsync the conf.d/wato files to restore the config, I have not run into any issues so far.

Backups are only util if you still have the checkmk server software available for the backup’s version. You have to take care of this yourself as a backup does not contain the checkmk server software.
Best practise can be e.g. to make a backup directly after upgrade, so that you can remove old backups and the old checkmk server software.