4 4 3:Replication

From SEPsesam
Other languages:

Template:Copyright SEP AG en

Icon archived docs.png This is not the latest version of SEP sesam documentation and, as such, does not provide information on features introduced in the latest release. For more information on SEP sesam releases, see SEP sesam Release Versions. For the latest documentation, check About Replication in v. ≥ Beefalo.


Overview

SEP sesam replication is designed to consistently replicate data between SEP sesam Remote Device Servers (RDS), which can also be SEP sesam Servers. This is advantageous in terms of redundancy for disaster recovery as well as in providing additional source for ordinary data restore. SEP sesam replication is used together with Si3 target deduplication, an inline block-level data deduplication solution that writes data directly from the SEP sesam Server or Remote Device Server (RDS) to the backup media. Storing only one instance of the data on backup media results in reduced amount of data backed up on storage. SEP Si3 target deduplication is easily configured and ready to use by selecting Si3 deduplication data store type. For details, see Configuring Si3 Deduplication Store. Combined with SEP sesam replication, it provides faster backup cycles and better SEP sesam performance.

SEP sesam replication searches only for new blocks of data on the source media pool and replicates those changes to a target media pool according to defined schedule. Replication means that only changed data blocks are sent over a network and backed up to the target server. This reduces the data transferred over the network and gives you ability to control your network usage by scheduling replication. To optimize replication performance, you cannot replicate savesets with errors. It is possible to replicate savesets with status successful, savesets with warnings (status successful or with warnings) or partially restorable savesets (containing data from cancelled backups).

Note that SEP sesam replication can be performed from n SEP sesam RDS (or SEP sesam Servers) to m SEP sesam RDS (or SEP sesam servers).

As of v. 4.4.3. Tigon, it is possible to use initial seed for setting up new Si3 deduplication store for the purpose of replication. For details, see Seeding Si3 Deduplication Store.

Information sign.png Note
If you are using SEP sesam v. 4.4.2, you must be aware of a constraining limitation related to the dependence of the replication savesets upon the properties and existance of the source (original) savesets: the EOL (end-of-life) of the replicated savesets is the same as the EOL of the source media pool. Therefore, if a saveset is deleted from the source media pool, it will be deleted from the target pool too. It is recommended to upgrade to the latest version, which solves this issue.


SEP Warning.png Warning
Two-way synchronization of Si3 data stores in v. 4.4.2

The latest update fixes the following serious bug, which occurs with v. 4.4.2 replication: instead of one-way data store synchronization that deletes savesets from the replication target data store if the same savesets were deleted from the source data store, SEP sesam also synchronizes the replication data stores the other way around. Therefore, deleting a target Si3 replication data store results in deletion of the corresponding savesets from the source data store! To prevent unwanted data loss, do not delete your target replication data store until upgrading to the latest version, which solves this issue. In case you need to delete a replication target data store with v. 4.4.2, contact SEP support at support@sep.de and ask for guidance.

Prerequisites

SEP sesam replicates data between a SEP sesam Server and an RDS or between two RDSs. Therefore, on a SEP sesam Server either two RDSs or one RDS in addition to the SEP sesam Server must be configured for the replication. For details on installing RDS, see How to configure Remote Device Server.

Since a SEP sesam Server is also a Device Server, the instructions below show how to configure replication between a SEP sesam Server and RDS, where SEP sesam Server can always be replaced by RDS.

To use replication, the following prerequisites must be met:

  • Both, SEP sesam Server and/or RDS (or more of them) must have the same SEP sesam version ≥ 4.4.2 installed. Note that you can have more than one RDS, but their SEP sesam version must match the SEP sesam Server version. Check Hardware requirements for SEP sesam Server or RDS.
  • Java must be installed on RDS and on deduplication clients. For details on the required Java version, see Java Compatibility Matrix.
  • A valid replication license Si3R is required for each Si3T node (SEP sesam Server or Remote Device Server).
  • A reliable network connection between servers. Note that NAT (Network Address Translation) infrastructure is not supported.
  • Bandwidth can affect replication performance. Test SEP sesam replication processing to determine how much workload can be managed by your network.
  • It is important that you ensure sufficient amount of memory and CPU.
  • The same amount of disk space is required for source and target data stores. Ensure that enough disk space is available for both data stores, always keeping in mind that horizontal scaling might be necessary.
  • Determine the type of data that is going to be replicated. You can reduce network load by elaborate scheduling and replication scenarios.
Information sign.png Note
Antivirus programs may disrupt network communication and cause SEP sesam processes, such as backup and replication, to fail. One program that is known to cause SEP sesam processes to terminate is Sophos Firewall with IPS (Intrusion Prevention System) enabled. Make sure that there are no antivirus, firewall, IDS or IPS programs preventing interaction with SEP sesam.

Configuring data replication

  1. Configure Si3 deduplication store on SEP sesam server. Before you begin, check the system requirements and recommendations. Again, make sure that you have enough disk space and that your storage can be extended for the needs of deduplication.
    Information sign.png Note

    Only one Si3 deduplication store can be configured on a server. For each Si3 deduplication store a valid license is required.
    You can also use initial seed for setting up new Si3 deduplication store for the purpose of replication. For details, see Seeding Si3 Deduplication Store.

  2. Configure media pool(s) for your deduplication store. Because the retention time is set on a media pool level, create media pools accordingly, for example, source_dedup_daily (proposed retention time: 7 days), source_dedup_weekly (proposed retention time: 30 days), source_dedup_monthly (proposed retention time: 200 days) media pool.
  3. Add one or more RDS as ordinary SEP sesam Clients: In the Main selection -> Components -> Topology, click New client. Make sure that you correctly define the Interfaces field in the New Client dialog to ensure a proper DNS connection among the SEP sesam Server and SEP sesam RDS. For details, see FAQ: Which are SEP sesam default TCPIP ports and How to check DNS configuration.
  4. Now configure a remote Si3 deduplication store on each SEP sesam RDS following the same system requirements and recommendations as before.
  5. Configure media pools for your remote deduplication store. The retention time set for the target replication media pool must be the same as for the source Si3 media pool (see Note), for example, target_dedup_daily (proposed retention time: 7 days), target_dedup_weekly (proposed retention time: 30 days), target_dedup_monthly (proposed retention time: 200 days) media pool.
  6. Information sign.png Note

    With v. 4.4.2, the EOL (end-of-life) of the replicated savesets is the same as the EOL of the source media pool. Therefore, if a saveset is deleted from the source media pool, it will be deleted from the target pool too. It is recommended to upgrade to the latest version, which solves this issue.

  7. Test both Si3 deduplication stores by executing a backup on each of them.
    • Create a new backup task: In the Main Selection -> Tasks -> By clients, select your RDS client and then click New backup task. Configure your backup task and save it. For details, see Creating a backup task.
    • Test the backup on the source Si3 datastore: From the menu bar, select Activities -> Immediate start -> Backup. In the Immediate start: Backup dialog, select a source_dedup media pool as your backup target media pool. Click Start and check if your backup performed successfully.
    • Test the backup on the target Si3 datastore: From the menu bar, select Activities -> Immediate start -> Backup. In the Immediate start: Backup dialog, select a target_dedup media pool as your backup target media pool. Click Start and check if your backup performed successfully.
  8. Create a replication task: In the Main selection -> Tasks -> Replication Tasks (previously Si3 Replications), click New replication task. The New replication task window is displayed.
  9. In the Name field, enter a meaningful name for the replication task, e.g., rep-source_mediapool-to-target_mediapool.
  10. Under the Parameters, specify the following:
    • Media pool
      • Pool: Enter the name of the source media pool from which the data will be replicated, e.g., source_mediapool.
      • Drive: Select the drive number of the drive that will be used to read the data.
    • Destination
      • Pool: Enter the name of the target media pool to which the data will be replicated, e.g., target_mediapool.
      • Information sign.png Note

        With v. 4.4.2, the EOL (end-of-life) of the target media pool will be ignored. If a saveset is deleted from the source media pool, it will also be deleted from the target media pool. It is recommended to upgrade to the latest version, which solves this issue.

      • Drive: Select the drive number of the drive that will be used to write the data.
      • Interface: Specify the network interface of the RDS through which the data transfer will be executed, e.g. the name of the RDS.
    • To define the time frame of the backups that will be replicated, select Relative backup date and select the appropriate values for the from/to fields. These fields specify the number of days in the past that are considered for replication, meaning all data in the source media pool that was backed up within a given period of time is going to be considered for replication to the remote pool. For example, to replicate all data from the past week, the Relative backup date is set to -7 while to is set to 0. Because the replication will always replicate only new blocks of data, you can specify a really high number in the from field, such as -99.999. This way all backups since the initial replication will always be checked, but only the changed data is going to be replicated.
    • Information sign.png Note

      Only the savesets with status successful and with warnings are selected for replication, whilst savesets with errors and only partially restorable savesets (containing data from cancelled backups) are not replicated.

    • In the drop-down list based on, the Sesam days option is selected by default. Sesam day is a backup day you define according to your backup routines. For example, your backups can run after midnight but retain the backup date of the prior day. Sesam day/backup day is defined by time set in the NEWDAY event. For details, see SEPuler: SEP sesam backup day.
    • Replication task 02.png
  11. Click Save to save your replication task.
  12. Replication task 01.png

Initial replication

An initial transfer of data will replicate all data from the source to target server, therefore it will require a bigger amount of CPU, network bandwidth and time to successfully complete. You should start initial replication manually. For all following replication cycles you can create different schedules, because after the initial replication the process will transfer only data that has changed on the source server.

To start replication manually, proceed as follows:

  1. From the menu, select Activities -> Immediate start -> Migration.
  2. In the Start migration window, from the Task name drop-down list, select the replication task you want to start and click Start migration.

To make sure that your replication finished successfully, check its status. For details, see Checking replication status.

Scheduling replication

You can add your replication task to one or more schedules to automate your replication.

  1. In the Main Selection -> Scheduling -> Schedules, click New schedule. The New schedule window appears.
  2. Schedule replication daily.png
  3. Configure your schedule and click OK. For details, see Creating a schedule.
  4. Right-click the schedule you have just created and select New Replication Event (previously New Migration Event). A new tab is opened in the schedule window.
  5. From the Task name drop-down list, select the task you want to link to the schedule. Optionally, in the Priority box, you can set up the Priority of your replication event. SEPuler always executes the schedules with higher priority first. Default priority level is 1, which is the lowest priority (the highest is 99). The only exception are the schedules with priority 0, which override all other priorities and are always executed. For details, see Setting Event Priorities. You can also enable the Blocking date. This option should be used together with high priority for special events. If checked, the blocking event will block events of the same type of a lower priority, ensuring the backup to be processed in case other backups are scheduled at the same time.
  6. Check the parameters and set filters, if needed, then click OK to link the event to the schedule.
  7. New migrat-replic event.png

Checking replication status

The status of your replication jobs is logged together with the migration jobs. Go to the Main Selection -> Job state -> Migrations and Replications and check your replication task in the first column Migration Task. The other columns provide details on status, start and end time, and media pools used for the task.

As of SEP sesam version 4.4.3. Tigon V2, you can also examine the progress of the replication and see how much data is being transferred; you can check data size, physical and nominal data in the columns Data Size, Transferred, Transferred (Brutto) and Progress, respectively. For example, if you are replicating 100 GB of data, just 1 GB needs to be transferred physically over the network because this data has changed.

Replication job status.png

Information sign.png Note

If the replication is scheduled, but there is nothing to replicate because the data has not changed since the last run, the displayed status in the column State is successful with remark no savesets found.


SEP Warning.png Warning
Two-way synchronization of Si3 data stores in v. 4.4.2

The latest update fixes the following serious bug, which occurs with v. 4.4.2 replication: instead of one-way data store synchronization that deletes savesets from the replication target data store if the same savesets were deleted from the source data store, SEP sesam also synchronizes the replication data stores the other way around. Therefore, deleting a target Si3 replication data store results in deletion of the corresponding savesets from the source data store! To prevent unwanted data loss, do not delete your target replication data store until upgrading to the latest version, which solves this issue. In case you need to delete a replication target data store with v. 4.4.2, contact SEP support at support@sep.de and ask for guidance.

See also

Configuring Si3 Deduplication StoreSeeding Si3 Deduplication Store