{"id":18305,"date":"2021-02-26T11:47:00","date_gmt":"2021-02-26T10:47:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=18305"},"modified":"2021-02-22T10:51:54","modified_gmt":"2021-02-22T09:51:54","slug":"periodische-replikation-mit-veritas-access","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=18305","title":{"rendered":"Periodische Replikation mit Veritas Access"},"content":{"rendered":"\n

Wenn Daten st\u00e4ndig miteinander abgeglichen werden, kommt eine Continuous Data Replication zum Einsatz \u2013 es besteht eine kontinuierliche Verbindung. Was aber, wenn t\u00e4glich etwa Daten aus Niederlassungen an das zentrale Rechenzentrum \u00fcberspielt werden m\u00fcssen? Hier kommt die episodische Replikation mit Veritas Access zum Zuge. Damit m\u00fcssen weder einzelne Ver\u00e4nderungen der Dateien in einer exakten Reihenfolge aktualisiert werden, noch muss die Konsistenz der Informationen gew\u00e4hrleistet sein. Die Terminierung dieser Aufgabe erfolgt unabh\u00e4ngig von den zeitkritischeren Sicherungsstreams der Anwendungen, die ihrerseits kontinuierlich und synchron erfolgen m\u00fcssen. Eine episodische Replikation wirkt sich besonders im Netzwerk ressourcensparend aus.<\/p>\n\n\n\n

\"\"<\/a>
Grafik: Veritas<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

F\u00fcr eine terminierbare Replizierung sind zwei miteinander verbundene Access-Systeme der gleichen Version notwendig \u2013 mit einer eigens konfigurierten virtuellen IP-Adresse (VIP) und einem gemeinsamen Schl\u00fcssel zur Authentifizierung des Quellsystems (Source) und des Zielmediums (Destination).<\/p>\n\n\n\n

Zur Vorbereitung legen Sie zun\u00e4chst auf dem Quellsystem in der Replication Unit eine Liste der zu kopierenden Informationsbest\u00e4nde fest. Hier finden sich Angaben \u00fcber das File-System, die Unterverzeichnisse sowie \u00fcber jede einzelne Datei. Was nicht zu sichern ist, kann auch in einer Exclusion Unit gesammelt werden. Anschlie\u00dfend werden die Metadaten \u00fcberpr\u00fcft, um den n\u00f6tigen Umfang der \u00c4nderungen auch auf Blockebene zu erkennen. Gegebenenfalls lassen sich nur einzelne Bl\u00f6cke \u00e4ndern.<\/p>\n\n\n\n

Im n\u00e4chsten Schritt verbinden Sie \u00fcber die Source die Zieleinheit. Durch die Befehle „episodic auth config“ und „episodic auth bind“ werden die n\u00f6tigen Authorisations-Keys abgefragt und die zu nutzende IP-Adresse des Ziels mitgeteilt. Nach Austausch der Schl\u00fcssel werden Verzeichnisse und Dateien auf der Destination angelegt und die \u00dcbertragung beginnt. Storage Checkpoints auf Source und Destination \u00fcberpr\u00fcfen den Erfolg. Sie helfen Ihnen bei sp\u00e4teren Rollbacks oder einer notwendigen Wiederherstellung.<\/p>\n\n\n\n

Die Jobs lassen sich zu jeder Zeit f\u00fcr andere wichtigere Aufgaben unterbrechen. Eine neue Sicherung startet stets erst nach Abschluss der alten. Sie ist sowohl bei einem geplanten Failover \u2013 weil ein System offline gehen muss \u2013 als auch bei einem ungeplanten Failover m\u00f6glich. Ein Reporting k\u00f6nnen Sie mit „replication episodic job stats <job_name>“ einsehen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Wenn Daten st\u00e4ndig miteinander abgeglichen werden, kommt eine Continuous Data Replication zum Einsatz \u2013 es besteht eine kontinuierliche Verbindung. Was aber, wenn t\u00e4glich etwa Daten aus Niederlassungen an das zentrale Rechenzentrum \u00fcberspielt werden m\u00fcssen? Hier kommt die episodische Replikation mit Veritas Access zum Zuge. Damit m\u00fcssen weder einzelne Ver\u00e4nderungen der Dateien in einer exakten Reihenfolge aktualisiert werden, noch muss die Konsistenz der Informationen gew\u00e4hrleistet sein. Die Terminierung dieser Aufgabe erfolgt unabh\u00e4ngig von den zeitkritischeren Sicherungsstreams der Anwendungen, die ihrerseits kontinuierlich und synchron erfolgen m\u00fcssen. Eine episodische Replikation wirkt sich besonders im Netzwerk ressourcensparend aus.<\/p>\n","protected":false},"author":1,"featured_media":18306,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[153,6],"tags":[1199,14687,2758,5513,9164],"class_list":["post-18305","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-backup","category-tipps","tag-access","tag-replication-unit","tag-replikation","tag-veritas","tag-vip"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/18305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=18305"}],"version-history":[{"count":1,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/18305\/revisions"}],"predecessor-version":[{"id":18308,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/18305\/revisions\/18308"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/media\/18306"}],"wp:attachment":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=18305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=18305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=18305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}