Difference between revisions of "Replication/de"

From SEPsesam
Jump to: navigation, search
Line 82: Line 82:
 
<li>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 [[Special:MyLanguage/Replication#Configuring data replication| 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.</li>
 
<li>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 [[Special:MyLanguage/Replication#Configuring data replication| 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.</li>
 
{{Anmerkung|
 
{{Anmerkung|
With v. 4.4.2, the [[Special:MyLanguage/SEP_sesam_Glossary#EOL|EOL]] (end-of-life) of the  replicated save sets is the same as the EOL of the source media pool. Therefore, if a save set is '''deleted from the source media pool''', it will be '''deleted from the target pool too'''. ''It is recommended to upgrade to the [https://download.sep.de/ latest version], which solves this issue.''}}
+
With v. 4.4.2, the [[Special:MyLanguage/SEP_sesam_Glossary#EOL|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 [https://download.sep.de/ latest version], which solves this issue.''}}
 
<li>Test both Si3 deduplication stores by executing a backup on each of them.
 
<li>Test both Si3 deduplication stores by executing a backup on each of them.
 
<ul><li>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 [[Special:MyLanguage/Creating_a_Backup_Task|Creating a backup task]].
 
<ul><li>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 [[Special:MyLanguage/Creating_a_Backup_Task|Creating a backup task]].
Line 106: Line 106:
 
<ul><li>'''Pool''': Enter the name of the target media pool to which the data will be replicated, e.g., ''target_mediapool''.</li>
 
<ul><li>'''Pool''': Enter the name of the target media pool to which the data will be replicated, e.g., ''target_mediapool''.</li>
 
{{Anmerkung|
 
{{Anmerkung|
With v. 4.4.2, the [[Special:MyLanguage/SEP_sesam_Glossary#EOL|EOL]] (end-of-life) of the target media pool will be ignored. If a save set is deleted from the source media pool, it will also be deleted from the target media pool. ''It is recommended to upgrade to the [https://download.sep.de/ latest version], which solves this issue.''}}
+
With v. 4.4.2, the [[Special:MyLanguage/SEP_sesam_Glossary#EOL|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 [https://download.sep.de/ latest version], which solves this issue.''}}
 
<li>'''Drive''': Select the drive number of the drive that will be used to write the data.</li>
 
<li>'''Drive''': Select the drive number of the drive that will be used to write the data.</li>
 
<li>'''Interface''': Specify the network interface of the RDS through which the data transfer will be executed, e.g. the name of the RDS.</li></ul>
 
<li>'''Interface''': Specify the network interface of the RDS through which the data transfer will be executed, e.g. the name of the RDS.</li></ul>
 
<li>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.</li>
 
<li>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.</li>
 
{{Anmerkung|
 
{{Anmerkung|
Only the save sets with status ''successful'' and ''with warnings'' are selected for replication, whilst save sets with errors and only partially restorable save sets (containing data from cancelled backups) are not replicated.}}
+
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.}}
  
 
<!--T:19-->
 
<!--T:19-->
Line 168: Line 168:
 
<br />
 
<br />
 
{{Achtung|'''Two-way synchronization of Si3 data stores in v. 4.4.2'''<br>
 
{{Achtung|'''Two-way synchronization of Si3 data stores in v. 4.4.2'''<br>
The [https://download.sep.de/ latest update] fixes the following serious bug, which occurs with v. 4.4.2 replication: instead of one-way data store synchronization that deletes save sets from the replication target data store if the same save sets 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 save sets from the source data store! To '''prevent unwanted data loss''', '''do not delete your target replication data store until upgrading to the [https://download.sep.de/ 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 [mailto:support@sep.de support@sep.de] and ask for guidance.}}
+
The [https://download.sep.de/ 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 [https://download.sep.de/ 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 [mailto:support@sep.de support@sep.de] and ask for guidance.}}
 
== Siehe auch ==
 
== Siehe auch ==
 
[[Special:MyLanguage/Configuring_an_Si3_Deduplication_Store|Konfiguration eines Si3 Deduplication Store]] – [[Special:MyLanguage/Seeding_Si3_Deduplication_Store|(Erst-)Befüllung eines Si3 Deduplication Stores für die Replikation (Initial Seed)]]
 
[[Special:MyLanguage/Configuring_an_Si3_Deduplication_Store|Konfiguration eines Si3 Deduplication Store]] – [[Special:MyLanguage/Seeding_Si3_Deduplication_Store|(Erst-)Befüllung eines Si3 Deduplication Stores für die Replikation (Initial Seed)]]

Revision as of 16:23, 8 November 2019

Other languages:
Deutsch • ‎English

Copyright © SEP AG 1999-2019. Alle Rechte vorbehalten.

Jede Form der Reproduktion der Inhalte dieses Benutzerhandbuches, ganz oder in Teilen, ist nur mit der ausdrücklichen schriftlichen Erlaubnis der SEP AG gestattet. Bei der Erstellung dieses Benutzerhandbuches wurde mit größtmöglicher Sorgfalt gearbeitet, um korrekte und fehlerfreie Informationen bereit stellen zu können. Trotzdem kann die SEP AG keine Gewähr für die Richtigkeit der Inhalte dieses Benutzerhandbuches übernehmen.

Docs latest icon.png Willkommen in der aktuellsten Version der SEP sesam Dokumentation 4.4.2/4.4.3 Beefalo. Frühere Versionen der Dokumentation finden Sie hier: Dokumentation Archiv.


Übersicht

Die SEP sesam Replikation wurde entwickelt, um Daten zwischen SEP sesam Remote Device Servern (RDS) konsistent zu replizieren, welche auch SEP sesam Server sein können. Dies ist sowohl in Bezug auf die Redundanz bei der Disaster Recovery als auch bei der Bereitstellung einer zusätzlichen Quelle für die normale Datenrücksicherung von Vorteil. Die SEP Sesam Replikation wird zusammen mit der Si3 zielseitigen Deduplizierung verwendet, einer Inline-Daten-Deduplizierungslösung auf Blockebene, die Daten direkt vom SEP Sesam Server oder Remote Device Server (RDS) auf die Sicherungsmedien schreibt. Das Speichern nur einer Instanz der Daten auf Sicherungsmedien führt zu einer geringeren Menge an Daten, die auf dem Speicher gesichert werden. Die SEP Si3 zielseiteige Deduplizierung ist einfach zu konfigurieren und einsatzbereit, indem Sie den Datenspeichertyp SEP Si3 Deduplication Store auswählen. Details finden Sie unter Konfiguration eines Si3 Deduplication Store. In Kombination mit der SEP sesam Replikation bietet es schnellere Sicherungszyklen und eine gesteigerte SEP sesam Performance.

Die SEP sesam Replikation sucht nur nach neuen Datenblöcken auf dem Quellmedienpool und repliziert diese Änderungen nach einem definierten Zeitplan in den Zielmedienpool. Replikation bedeutet, dass nur geänderte Datenblöcke über ein Netzwerk gesendet und auf den Zielserver gesichert werden. Dies reduziert die über das Netzwerk übertragenen Daten und gibt Ihnen die Möglichkeit, Ihre Netzwerknutzung durch die Planung der Replikation zu kontrollieren. Um die Replikationsperformance zu optimieren, können Sie fehlerhafte Sicherungssätze nicht replizieren. Es ist möglich, Sicherungssätze mit Status erfolgreich, Sicherungssätze mit Warnungen (Status erfolgreich oder mit Warnungen) oder teilweise wiederherstellbare Sicherungssätze (mit Daten aus abgebrochenen Sicherungen) zu replizieren.

Beachten Sie, dass die SEP sesam Replikation von n SEP sesam RDS (oder SEP sesam Servern) auf m SEP sesam RDS (oder SEP sesam Server) durchgeführt werden kann.

Ab V. 4.4.3. Tigon ist es möglich, mit Hilfe von Initial Seed (Erstbefüllung) einen neuen Si3 Deduplication Store für die Replikation einzurichten. Details finden Sie unter Befüllen eines Si3 Deduplication Store.

Information sign.png Anmerkung
Wenn Sie SEP sesam V. 4.4.2 verwenden, beachten Sie die Einschränkungen in Bezug auf Abhängigkeit der Replikationssicherungssätze bzgl. Eigenschaften und dem Vorhandensein der Quell-(Original-)Speichersätze: die EOL (End-of-Life) der replizierten Sicherungssätze ist identisch mit der EOL des Quellmedienpools. Wenn also ein Sicherungssatz aus dem Quellmedienpool gelöscht wird, wird er auch aus dem Zielpool der Replikation gelöscht. Es wird empfohlen, auf die neueste Version zu aktualisieren, die dieses Problem löst.


SEP Warning.png Achtung
Zweiwege-Synchronisation von Si3 Deduplication Store in V. 4.4.2.

Die letzte SEP sesam Aktualisierung behebt den folgenden schwerwiegenden Fehler, der bei der Replikation von V. 4.4.2 auftritt: Statt einer einseitigen Datenspeichersynchronisation, die Sicherungssätze aus dem Zieldatenspeicher der Replikation löscht, wenn dieselben Sicherungssätze aus dem Quelldatenspeicher gelöscht wurden, synchronisiert SEP sesam auch den Replikationsdatenspeicher umgekehrt. Das Löschen eines Si3-Replikationsdatenspeichers führt daher zum Löschen der entsprechenden Sicherungssätze aus dem Quelldatenspeicher! Um unerwünschten Datenverlust zu vermeiden, löschen Sie Ihren Ziel-Replikationsdatenspeicher erst nach der Aktualisierung auf die neueste Version, die dieses Problem behebt. Falls Sie einen Replikationzieldatenspeicher mit V. 4.4.2 löschen müssen, wenden Sie sich an den SEP-Support unter support@sep.de und fragen Sie nach einer Anleitung.

Voraussetzungen

SEP sesam repliziert Daten zwischen einem SEP sesam Server und einem RDS oder zwischen zwei RDS. Daher müssen auf einem SEP sesam Server entweder zwei RDS oder ein RDS zusätzlich zum SEP sesam Server für die Replikation konfiguriert werden. Weitere Informationen zur Installation von RDS finden Sie unter Wie richte ich einen Remote Device Server ein.

Da ein SEP sesam Server auch ein Device Server ist, zeigen die folgenden Anweisungen, wie Sie die Replikation zwischen einem SEP sesam Server und RDS konfigurieren, wobei der SEP sesam Server immer durch RDS ersetzt werden kann.

Um die Replikation nutzen zu können, müssen die folgenden Voraussetzungen erfüllt sein:

  • Sowohl auf dem SEP sesam Server als auch auf dem (oder den) RDS muss die gleiche SEP sesam Version ≥ 4.4.2 installiert sein. Beachten Sie, dass Sie mehr als ein RDS haben können, aber deren SEP sesam Version muss mit der SEP sesam Server Version übereinstimmen. Überprüfen Sie die Hardware Anforderungen auf dem SEP sesam Server oder dem RDS.
  • Java muss auf dem RDS und auf den Deduplizierungs-Clients installiert sein. Details zur benötigten Java Version finden Sie unter Java Kompatibilitäts-Matrix.
  • Für jeden Si3T-Knoten (SEP sesam Server oder Remote Device Server) ist eine gültige Replikationslizenz Si3R erforderlich.
  • Eine zuverlässige Netzwerkverbindung zwischen Servern. Beachten Sie, dass die NAT-Infrastruktur (Network Address Translation) nicht unterstützt wird.
  • Die Bandbreite kann die Replikationsleistung beeinträchtigen. Testen Sie die SEP sesam Replikationsverarbeitung, um festzustellen, wie viel Arbeitslast von Ihrem Netzwerk verwaltet werden kann.
  • Es ist wichtig sicher zu stellen, dass Sie eine ausreichende Menge an Speicher und CPU haben.
  • Für Quell- und Zieldatenspeicher wird gleiche Menge an Festplattenspeicher benötigt. Stellen Sie sicher, dass für beide Datenspeicher genügend Festplattenspeicher zur Verfügung steht, wobei Sie immer daran denken, dass eine horizontale Skalierung erforderlich sein könnte.
  • Bestimmen Sie die Art der Daten, die repliziert werden sollen. Sie können die Netzwerkbelastung durch ausgefeilte Planungs- und Replikationsszenarien reduzieren.
Information sign.png Anmerkung
Antivirenprogramme können die Netzwerkkommunikation stören und zu einem Ausfall von SEP sesam Prozessen wie Sicherung und Replikation führen. Ein Programm, von dem bekannt ist, dass es dazu führt, dass SEP sesam Prozesse beendet werden, ist Sophos Firewall mit aktiviertem IPS (Intrusion Prevention System). Achten Sie darauf, dass keine Antiviren-, Firewall-, IDS- oder IPS-Programme vorhanden sind, die eine Interaktion mit SEP sesam verhindern.

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 Anmerkung

    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 Anmerkung

    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 migration 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 Anmerkung

        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 Anmerkung

      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 de.jpg


  11. Click Save to save your replication task.
  12. Si3 replication task de.jpg

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 de.jpg

  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 de.jpg

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 de.jpg

Information sign.png Anmerkung

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 Achtung
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.

Siehe auch

Konfiguration eines Si3 Deduplication Store(Erst-)Befüllung eines Si3 Deduplication Stores für die Replikation (Initial Seed)