1 (edited by aadsi 2022-09-27 09:59:15)

Topic: Restoring from backup without upgrading

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 0.8.7
- Deployed with iRedMail Easy or the downloadable installer? Manual
- Linux/BSD distribution name and version: CentOS 6.5 (Old Box) Debian 11 (New Box)
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL (Old Box) MariaDB (New Box)
- Web server (Apache or Nginx): Apache
- Manage mail accounts with iRedAdmin-Pro? Yes (1.8.2)
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

I'm in the process of restoring a backup of a former mail server that ran iRedMail 0.8.7 with iRedAdmin-Pro v1.8.2. Restoring the backups and performing an upgrade to the latest version appears to be a bit cumbersome with how out of date this box was.

What is lost if I just install a new box with the latest iRedMail and iRedAdmin-Pro?

The plan would be installing the latest versions, create the users again, and then restore the vmail directories into the newly made accounts. In my limited testing dropping the mail files back in the proper Maildir folders makes the appear in the webmail interface for the accounts.

Is there a better way to do this?

I can get the former aliases and passwords from a restore of the old iredadmin database I believe? Is there any change in how passwords were hashed or could I just bring over the old password hashes so users do not need to reset that?

Thank you for any insight you can provide. I've also sent in an email to see if I can get the license file for iRedAdmin-Pro regenerated for this new hardware that is replacing a failed hardware installation.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 (edited by aadsi 2022-09-28 04:40:05)

Re: Restoring from backup without upgrading

I've managed to do a restore as I discussed above where I manually added the domains, then the email accounts that were active, and finally any aliases that mapped to accounts. From there I used rsync to bring back in the maildir's I restored from backups for the users which were remade on the new system.

Using my method I only found few problems that I'd like feedback on.

  1. The dashboard system information for amount of stored email no longer is correct

  2. The quota column for amount consumed on the domains and accounts page is not correct

  3. Passwords do not come over as the old version used salted MD5 which I did not want to bring back.

Now I've seen other threads where it is mentioned that the dashboard relies on the SQL databases for tracking these items. One being that Amavis stores stats in the amavisd database. I did not restore this database from the old system as I was concerned with the large version gap there could be schema discrepancies.

What I've not seen is mention of any way to catch up the dashboard with the new actual disk usage values. Is there a way to get them back in sync so the portal properly reflects actual consumption? I'm not opposed to writing code to update the needed values for situations like this but I'm not sure which databases I need to update.

Thoughts?

3

Re: Restoring from backup without upgrading

FYI https://docs.iredmail.org/migrate.to.ne … erver.html

4 (edited by aadsi 2022-09-30 05:57:58)

Re: Restoring from backup without upgrading

aadsi wrote:

I've managed to do a restore as I discussed above where I manually added the domains, then the email accounts that were active, and finally any aliases that mapped to accounts. From there I used rsync to bring back in the maildir's I restored from backups for the users which were remade on the new system.

Using my method I only found few problems that I'd like feedback on.

  1. The dashboard system information for amount of stored email no longer is correct

  2. The quota column for amount consumed on the domains and accounts page is not correct

  3. Passwords do not come over as the old version used salted MD5 which I did not want to bring back.

Now I've seen other threads where it is mentioned that the dashboard relies on the SQL databases for tracking these items. One being that Amavis stores stats in the amavisd database. I did not restore this database from the old system as I was concerned with the large version gap there could be schema discrepancies.

What I've not seen is mention of any way to catch up the dashboard with the new actual disk usage values. Is there a way to get them back in sync so the portal properly reflects actual consumption? I'm not opposed to writing code to update the needed values for situations like this but I'm not sure which databases I need to update.

Thoughts?

I did a bit more digging on this today and got the dashboard to properly show quota stats correctly again without needing to bring back any data from the amavisd database like I was thinking. I just needed to force dovecot to recalculate the quotas and iRedMail picked it right up.

https://docs.iredmail.org/recalculate.m … quota.html