Pre-Upgrade Steps: Difference between revisions
(Created page with "{{Article Infobox|{{admin}}||{{ZCS 8.0}}|{{ZCS 7.0}}|{{ZCS 6.0}}|{{ZCS 5.0}}|}}==Pre-Upgrade Steps== = Pre-Upgrade Steps = Before upgrading your Zimbra platform, we would st...") |
No edit summary |
||
(16 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{ | {{BC|Certified}} | ||
__FORCETOC__ | |||
<div class="col-md-12 ibox-content"> | |||
=Pre-Upgrade Steps= | |||
{{KB|{{ZC}}|{{ZCS 8.0}}|{{ZCS 7.0}}|}} | |||
{{WIP}} | |||
Before upgrading your Zimbra platform, we would strongly recommend the following pre-upgrade steps: | |||
= Prepare = | |||
Always read (in full) the Release Notes for the version to which you are upgrading. The Release Notes are available for every release: | |||
http://www.zimbra.com/downloads/ne-downloads.html | http://www.zimbra.com/downloads/ne-downloads.html | ||
= Test = | |||
Always always always test the upgrade first in a test lab and/or VM. This means using the same versions as your production versions, including any customizations or other modifications you have, and then running the upgrade to the same target version. Even better is to snap or clone your production system(s) into the Test Lab for doing a full upgrade test that mirrors production. Major Upgrades (e.g., ZCS7 to ZCS8) do often make changes to schema and tables that can vary based on database variations. | |||
= Check your database integrity = | |||
http://wiki.zimbra.com/wiki/Zmdbintegrityreport | |||
$ /opt/zimbra/libexec/zmdbintegrityreport -v | |||
= Backup your system = | |||
There are multiple ways to perform backups. Since upgrading permanently alters your system, it is mandatory to backup your system before you upgrade. The only recovery from a failed upgrade may be to restore from backups: | There are multiple ways to perform backups. Since upgrading permanently alters your system, it is mandatory to backup your system before you upgrade. The only recovery from a failed upgrade may be to restore from backups: | ||
== zmbackup your entire system == | |||
https://wiki.zimbra.com/wiki/CLI_-_zmbackup_Network_Edition_Only | https://wiki.zimbra.com/wiki/CLI_-_zmbackup_Network_Edition_Only | ||
Line 19: | Line 34: | ||
Note: this may take multiple hours, be sure to plan in advance: | Note: this may take multiple hours, be sure to plan in advance: | ||
zmbackup -f | $ zmbackup -f | ||
== Backup your LDAP data == | |||
http://wiki.zimbra.com/wiki/LDAP_data_import_export | |||
LDAP Main database: | |||
$ /opt/zimbra/libexec/zmslapcat /var/tmp | |||
LDAP Config database: | |||
$ /opt/zimbra/libexec/zmslapcat -c /tmp | |||
LDAP Accesslog database (on LDAP Master only): | |||
$ /opt/zimbra/libexec/zmslapcat -a /tmp | |||
== Backup your MySQL data == | |||
https://wiki.zimbra.com/wiki/MySQL_Backup_and_Restore | |||
# su - zimbra | |||
$ source ~/bin/zmshutil | |||
$ zmsetvars | |||
If using binary logging, the dump is run like the following: | |||
$ /opt/zimbra/mysql/bin/mysqldump --user=root --password=$mysql_root_password --socket=$mysql_socket \ | |||
--all-databases --single-transaction --master-data --flush-logs > {dump-file}.sql | |||
If not using binary logging, the dump is run like the following: | |||
$ /opt/zimbra/mysql/bin/mysqldump --user=root --password=$mysql_root_password --socket=$mysql_socket \ | |||
--all-databases --single-transaction --flush-logs > {dump-file}.sql | |||
== Snapshot Your Data == | |||
If using a hypervisor or storage that can perform snapshots, it is a great idea to take a snapshot immediately prior to your upgrade. In the case of a critical problem, this may be the DR recovery method that saves you significant time and effort. | |||
If using vSphere/ESXi, be sure to merge your snapshots back into main after the successful upgrade, because snapshots left around can consume significant data volume. | |||
= | = Confirm that your SSL certs are all valid and not-expired = | ||
http://wiki.zimbra.com/wiki/Administration_Console_and_CLI_Certificate_Tools | |||
# /opt/zimbra/bin/zmcertmgr viewdeployedcrt all | |||
= Conclusion = | |||
If any of the above steps fail in any way, DO NOT UPGRADE. They must all succeed before you continue. | |||
---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ||
{{Article Footer|ZCS 8.0 ZCS 7.0 | | {{Article Footer|ZCS 8.0 ZCS 7.0 |01/15/2014}} | ||
[[Category:Certified]] | |||
[[Category: Certificates]] | [[Category: Certificates]] | ||
[[Category:Backup and Restore]] | |||
[[Category:Disaster Recovery]] | |||
[[Category: ZCS 8.0]] | [[Category: ZCS 8.0]] | ||
[[Category: ZCS 7.0]] | [[Category: ZCS 7.0]] |
Latest revision as of 01:10, 11 July 2015
Pre-Upgrade Steps
Before upgrading your Zimbra platform, we would strongly recommend the following pre-upgrade steps:
Prepare
Always read (in full) the Release Notes for the version to which you are upgrading. The Release Notes are available for every release:
http://www.zimbra.com/downloads/ne-downloads.html
Test
Always always always test the upgrade first in a test lab and/or VM. This means using the same versions as your production versions, including any customizations or other modifications you have, and then running the upgrade to the same target version. Even better is to snap or clone your production system(s) into the Test Lab for doing a full upgrade test that mirrors production. Major Upgrades (e.g., ZCS7 to ZCS8) do often make changes to schema and tables that can vary based on database variations.
Check your database integrity
http://wiki.zimbra.com/wiki/Zmdbintegrityreport
$ /opt/zimbra/libexec/zmdbintegrityreport -v
Backup your system
There are multiple ways to perform backups. Since upgrading permanently alters your system, it is mandatory to backup your system before you upgrade. The only recovery from a failed upgrade may be to restore from backups:
zmbackup your entire system
https://wiki.zimbra.com/wiki/CLI_-_zmbackup_Network_Edition_Only
Note: this may take multiple hours, be sure to plan in advance:
$ zmbackup -f
Backup your LDAP data
http://wiki.zimbra.com/wiki/LDAP_data_import_export
LDAP Main database:
$ /opt/zimbra/libexec/zmslapcat /var/tmp
LDAP Config database:
$ /opt/zimbra/libexec/zmslapcat -c /tmp
LDAP Accesslog database (on LDAP Master only):
$ /opt/zimbra/libexec/zmslapcat -a /tmp
Backup your MySQL data
https://wiki.zimbra.com/wiki/MySQL_Backup_and_Restore
# su - zimbra $ source ~/bin/zmshutil $ zmsetvars
If using binary logging, the dump is run like the following:
$ /opt/zimbra/mysql/bin/mysqldump --user=root --password=$mysql_root_password --socket=$mysql_socket \ --all-databases --single-transaction --master-data --flush-logs > {dump-file}.sql
If not using binary logging, the dump is run like the following:
$ /opt/zimbra/mysql/bin/mysqldump --user=root --password=$mysql_root_password --socket=$mysql_socket \ --all-databases --single-transaction --flush-logs > {dump-file}.sql
Snapshot Your Data
If using a hypervisor or storage that can perform snapshots, it is a great idea to take a snapshot immediately prior to your upgrade. In the case of a critical problem, this may be the DR recovery method that saves you significant time and effort.
If using vSphere/ESXi, be sure to merge your snapshots back into main after the successful upgrade, because snapshots left around can consume significant data volume.
Confirm that your SSL certs are all valid and not-expired
http://wiki.zimbra.com/wiki/Administration_Console_and_CLI_Certificate_Tools
# /opt/zimbra/bin/zmcertmgr viewdeployedcrt all
Conclusion
If any of the above steps fail in any way, DO NOT UPGRADE. They must all succeed before you continue.