Zimbra Next Generation Modules/Zimbra NG Backup/Multistore Informations: Difference between revisions

mNo edit summary
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
<div class="col-md-12"><br></div>
#REDIRECT [[Zimbra_NG_Modules/Zimbra_NG_Backup/Multistore_Informations]]
<div class="col-md-12"><br></div>
<ol class="breadcrumb">
  <li>[[Main Page|Zimbra Wiki]]</li>
  <li>[[Zimbra_Next_Generation_Modules]]</li>
  <li>[[Zimbra_NG_Backup]]</li>
  <li class="active"> Multistore Informations</li>
</ol>
__NOTOC__
<div class="col-md-12"><br /></div>
<div class="col-md-9">
    <h2 class="title-header" style="padding-bottom: 9px; border-bottom: 4px solid #0087c3;">Zimbra NG Backup -  Multistore Informations</h2>
    <div class="col-md-12">
        <div class="ibox-content">
            <div class="post animated fadeInLeft animation-delay-8" style="padding-top:5px">
                <div class="panel panel-default">
                    <div class="panel-body">
                        <h5 class="post-title">Zimbra NG Backup -  Multistore Informations</h5>
                        <div class="row">
==Zimbra NG Backup and Multistores==
Zimbra Next Generation Modules comes with the long-awaited Multistore support. This means that now the Zimbra NG Backup module can be used on Zimbra environments consisting of multiple mailbox servers.
 
This short paper explains how to use Zimbra NG Backup on a multistore environment.
 
==Zimbra NG Backup in a Multistore Environment==
===Command execution in a Multistore Environment===
The new Zimbra Next Generation Modules Administration Zimlet makes the management of multiple servers very easy. You can select a server from the Zimbra NG Backup tab and perform all backup operations on that server, even if you are logged into the Zimbra Administration Console of another server. See the standard [[Zimbra_Next_Generation_Modules/Zimbra_NG_Backup/Admin_Guide|Zimbra NG Backup Admin Guide]] to learn how to perform basic backup operations.
 
This also applies to the [[Zimbra_Next_Generation_Modules/CLI|CLI]]. Operations can be launched on any server using the ''--host [hostname|ip]'' option.
 
Specific differences between Singlestore and Multistore environments are:
 
* In a Multistore Environment, Restore on New Account operations ALWAYS create the new account in the Source account's mailbox server.
* All operations are logged on the target server, not in the server that launched the operation.
* If a wrong target server for an operation is chosen, Zimbra automatically proxies the operation request to the right server.
 
===Backup and Restore===
Backup and Restore in a Multistore environment will work exactly like in a Singlestore environment.
 
The different servers will be configured and managed separately via the Zimbra Next Generation Modules Adminsitration Zimlet, but certain operations like Live Full Scan and Stop All Operations can be 'broadcast' to all the mailstores via the ''zxsuite'' CLI using the ''--hostname all_servers'' option. This applies also to Zimbra NG Backup settings (see the Zimbra Next Generation Modules CLI wiki page for more details).
 
Backup and Restore operations are managed as follows:
 
* Live full scans can be executed on single servers via the Zimbra Next Generation Modules Administration Zimlet or on multiple servers via the Zimbra Next Generation Modules CLI.
* Restores can be started from the "Accounts" tab in the Zimbra Admin Console, from each server tab in the Zimbra NG Backup menu of the Zimbra Next Generation Modules Administration Zimlet and via the Zimbra Next Generation Modules CLI. The differences between these methods are:
{| border=1 align="center"
! Operation started from:
! Options
|-
| "Accounts tab" || The selected account's restore is automatically started in the proper server.
|-
| "Server tab" || Any accounts eligible for a restore on the selected server can be chosen as the restore 'source'
|-
| "Zimbra Next Generation Modules CLI" || Any account on any server can restored, but there is no automatic server selection.
|}
 
===Export and Import===
Export and Import functions are those which differ the most when performed on a Multistore environment.
 
Here are the basic scenarios:
 
====Export from a Singlestore and import to a Multistore====
Importing multiple accounts of a single domain to different store will break the consistency of ALL the items that are shared from/to a mailbox on a different server.
 
Starting with Zimbra Next Generation Modules 1.0.0-RC3 a new command in the Zimbra Next Generation Modules CLI has been added in order to fix the shares for accounts of the same domain imported in differen servers.
 
====Export from a Multistore and import to a Single or Multistore====
Two different Scenarios apply here:
 
* "Mirror" import: Same number of source and destination mailstores, each export is imported on a different server. This will break the consistency of ALL the items that are shared from/to a mailbox on a different server. The `doCheckShares` and `doFixShares` CLI commands are available to check and fix share consistency (see below).
 
* "Composite" import: Same or different number of source and destination servers. Domains or accounts are manually imported into different servers. This will break the consistency of ALL the items that are shared from/to a mailbox on a different server. The `doCheckShares` and `doFixShares` CLI commands are available to check and fix share consistency (see below)
 
=== The `doCheckShares` and `doFixShares` commands===
The `doCheckShares` command will parse all share informations in local accounts and report any error:
 
<pre>
zimbra@test:~$ zxsuite help backup doCheckShares
 
Syntax:
  zxsuite backup doCheckShares
 
 
Usage example:
 
zxsuite backup doCheckShares
Check all shares on local accounts
 
</pre>
 
The `doFixShares` will fix all share inconsistencies using a migration [[Zimbra_Next_Generation_Modules/Zimbra_NG_Backup/Store#Map_Files|mapfile]] as the reference. Mapfiles can be found in the Backup Path of the destination server (default: /opt/zimbra/backup/zextras) and are named "map_{source_server_ID}".
 
<pre>
zimbra@test:~$ zxsuite help backup doFixShares
 
Syntax:
  zxsuite backup doFixShares {import_idmap_file}
 
 
PARAMETER LIST
 
NAME                    TYPE     
import_idmap_file(M)    String   
 
(M) == mandatory parameter, (O) == optional parameter
 
Usage example:
 
zxsuite backup doFixShares idmap_file
Fixes the shares' consistency after an import according to the mapping contained in the /opt/zimbra/backup/zextras/idmap_file
</pre>
                        </div>
                    </div>
                    <div class="col-md-9">
                        <div class="panel-footer">
                            <p><i class="fa fa-clock-o"></i> Aug 25, 2016 - [https://www.zimbra.com/email-server-software/ Know more »]</p>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>
<div class="col-md-3"><br /></div>
<div class="col-md-3">
    <div class="panel panel-zimbrared-light-border">
        <div class="panel-heading">
            <h3 class="panel-title"><i class="fa fa-gear pull-left"></i> Zimbra Next Generation Modules</h3>
        </div>
        <div class="panel-body">
            {{ZNG}}
        </div>
    </div>
</div>
<div class="col-md-3">
    <div class="panel panel-primary-light-border">
        <div class="panel-heading">
            <h3 class="panel-title"><i class="fa fa-info-circle pull-left"></i> Zimbra Next Generation Modules Resources</h3>
        </div>
        <div class="panel-body">
            {{ZNGL}}
        </div>
    </div>
</div>
<div class="clearfix"></div>
<div class="col-md-12"><br></div>
{{FH}}

Latest revision as of 12:52, 29 November 2017

Jump to: navigation, search