Error Valid backup file not found upgrading from 5.0.18 to 6

[Nextasy]

Quick status report.

dunno why, but i find an actual ldap.bak in /temp with 69 kybte. copied it to /opt/zimbra/data/ldap/ dir - and started zmsetup.pl - but same error. the script overwrites the ldap.bak with a 0 byte version. hmm...chmod 440 on ldap.bak and restart zmsetup.pl - now it goes above this error - and still updating at this time

[Nextasy]

thx for help - its now solved.

[chameleons84]

Hello,

I have the exact same issue how was this solved in the end?

thanks

[romat]

Originally Posted by Nextasy

thx for help - its now solved.

Same for me. I have the exact same phenomenon when updating to 6.0 and desperately would like to know what action actually solved this problem. Thanx for reply

[phoenix]

Post #31 would appear to have the answer, does that not work for you?

[chameleons84]

Post #31 did nto work for me. I could not find a ldap.bak in temp, I am running Fedora 7, so /tmp. I also tried to restoring from backup earlier and it failed.

[mmorse]

Bug 43591 – ldap.bak issues on GNR upgrades

Quanah also pointed out that depending on when you create this ldap.bak (if your not using one that was created earlier like ldap.bak.timestamp) have to be using the 5.0 slapcat/sleepycatlibs for BDB differences with 6.0 to get a valid backup.

[regan.wallace]

Just to add one more touch;

I was able to find an ldap.bak in the still existing openldap-data directory, copy it over to data/ldap and chmod 440, rerun /opt/zimbra/libexec/zmsetup.pl and it worked like a charm.


At first I thought I b0rked my install, by trying to go from 5.0.20 > 6.0.0; when it failed, I figured that was the cause of 6.0.3 breaking.

I hope that helps someone out there

[romat]

sorry guys, i wanted to post my experience in that topic but i have forgotten to post it yet.

Since i had not found any ldap.bak file in the mentioned directories either, i saw my last change in redoing the whole upgrade process again from scratch. so after another restore of a blank machine, replaying the bakup and starting the upgrade sequence, i was at that point and the upgrade script did not stop at that time and the upgrade finished without any problems.

So this was my experience with that incident in this case. From that day on i have a functional system running for about 4 weeks now.

[dcampbell]

I ran into the same problem.. fortunately, in the folder (/opt/zimbra/data/ldap), there was a backup with the first timestamp that wasn't 0 size- *copied* it to ldap.bak and chmod to 440 and the install worked past that point.