WISSEN > CLOUD INFRASTRUKTUR > DATEN ZWISCHEN CLOUD UN ON-PREMISES BEWEGERN

Migration, Replikation, Tiering und Backup technisch unterschieden

 

Autor: Dirk Neumann                Geschäftsführer ASSISTRA Cloud Services GmbH                            17.08.2026

Daten zwischen Cloud und On-Premises bewegen


Das sollten Sie mitnehmen:
 

  1. Datenbewegung ist nicht gleich Migration.
    Migration, Replikation, Synchronisation, Tiering und Backup verfolgen unterschiedliche Ziele und erfordern unterschiedliche Verfahren.
     
  2. Die nominelle Bandbreite bestimmt die Transferdauer nicht allein.
    Maßgeblich ist der gemessene End-to-End-Durchsatz über den gesamten Pfad von der Quelle bis zum Zielsystem.
     
  3. Die Änderungsrate entscheidet über den Erfolg.
    Liegt sie über der erreichbaren Transferleistung, kann ein Delta-Abgleich den Rückstand nicht abbauen.
     
  4. Offline-Transfer ist eine Option, aber keine Abkürzung.
    Kopierzeit, Logistik, Import und ein anschließender Delta-Abgleich müssen gegen den Netzweg gerechnet werden.
     
  5. Der Zielzustand muss vor dem Transfer feststehen.
    Ob Daten einmal verlagert, repliziert, synchronisiert, ausgelagert oder gesichert werden, bestimmt jedes weitere Detail.

Inhaltsverzeichnis

Daten zwischen einer lokalen Infrastruktur und einer Cloud zu bewegen wirkt zunächst wie eine reine Übertragungsaufgabe. Technisch unterscheiden sich eine einmalige Migration, eine kontinuierliche Replikation, eine Synchronisation, Storage Tiering und Backup jedoch grundlegend voneinander. 

Die entscheidende Frage lautet deshalb nicht nur, wie viele Daten übertragen werden müssen. Ebenso wichtig ist, warum sie bewegt werden, wie häufig sie sich ändern und welchen Zustand beide Seiten nach der Übertragung besitzen sollen. 

Bei großen oder laufend veränderten Datenbeständen werden Netzwerkbandbreite, Latenz, Anzahl und Größe der Dateien oder Objekte, Änderungsrate, Parallelisierung, Konsistenzanforderungen und mögliche Transferkosten damit zu Architekturparametern. 

1. Hybride Architekturen besitzen zwangsläufig Datenpfade 

Hybride Infrastrukturen verbinden unterschiedliche Standorte und administrative Domänen. Cloud Storage kann darin Ziel einer Migration sein, zusätzliche Datenkopie, Backup-Ziel oder Storage Tier. 

Ebenso relevant ist die Gegenrichtung. Daten können aus einer Cloud zurück in ein eigenes Rechenzentrum, zu einem anderen Anbieter oder auf eine andere Storage-Plattform übertragen werden. 

Die Portabilität von Daten gehört damit zur Cloud-Architektur und ist kein Sonderfall. Die Cloud Data Management Interface (CDMI) der SNIA, standardisiert als ISO/IEC 17826:2022, adressiert unter anderem interoperables Datenmanagement und Datenportabilität für Cloud-, Hybrid- und On-Premises-Storage. 

Zuvor ist jedoch zu klären, welche Form der Datenbewegung überhaupt benötigt wird. 

2. Migration, Replikation, Synchronisation, Tiering und Backup sind nicht dasselbe 

Tabelle vergleicht Migration, Replikation, Synchronisation, Tiering und Backup nach Richtung, Zielzustand und Zeitverhalten.

 Migration verlagert einen Datenbestand einmalig 

Eine Migration überführt einen definierten Datenbestand von einem Quell- in ein Zielsystem. Der typische Ablauf besteht aus Initialtransfer, Delta-Abgleich, Validierung und Cutover. 

Bei aktiven Datenbeständen liegt die Schwierigkeit darin, dass sich die Quelle während der Übertragung weiter verändert. Dauert ein Initialtransfer mehrere Tage, können Dateien oder Objekte aus der Anfangsphase bei Abschluss bereits überholt sein. Ein tragfähiges Migrationsverfahren muss solche Änderungen deshalb erkennen und nachführen oder Schreibzugriffe während einer definierten Phase unterbinden. 

Der Initialtransfer allein ist damit keine abgeschlossene Migration. 

Replikation erzeugt eine fortlaufende Kopie 

Replikation verfolgt ein anderes Ziel. Die SNIA definiert Data Replication als kontinuierliche Aufrechterhaltung einer Datenkopie, gegebenenfalls an einem entfernten Standort, unter anderem für Redundanz, Hochverfügbarkeit oder Disaster Recovery. 

Zu unterscheiden ist dabei zwischen synchroner und asynchroner Replikation. Bei synchroner Replikation muss ein Schreibvorgang laut SNIA sowohl am primären als auch am sekundären Standort auf stabilem Storage committed sein, bevor er gegenüber dem Host bestätigt wird. Der entfernte Schreibpfad wird damit Bestandteil der Write-Latency. 

Bei asynchroner Replikation genügt der Commit am primären Standort für die Bestätigung. Die Daten werden anschließend entsprechend den verfügbaren Netzwerkressourcen zum Sekundärsystem übertragen. Zwischen beiden Systemen kann deshalb zeitweise ein unterschiedlicher Datenstand bestehen. 

Replikation ist außerdem kein Backup. Wird eine unerwünschte Änderung repliziert, erreicht sie auch die Replik. Für die Wiederherstellung früherer Zustände sind zusätzliche Mechanismen nötig. Die SNIA führt dafür den eigenständigen Begriff Continuous Data Protection: eine Klasse von Mechanismen, die Datenänderungen fortlaufend erfassen oder nachverfolgen und dadurch eine Wiederherstellung auf frühere Zeitpunkte ermöglichen. 

Synchronisation gleicht Zustände ab und muss Konflikte auflösen 

Bei einer Synchronisation werden Zustände zwischen Systemen verglichen und Änderungen übertragen. Das kann einseitig erfolgen oder, abhängig von der Implementierung, in beide Richtungen. 

Bidirektionale Verfahren werfen eine zusätzliche Frage auf: Was geschieht, wenn dasselbe Datenelement an mehreren Stellen verändert wurde? Dann werden eine Konflikterkennung und Regeln für die Konfliktauflösung benötigt. 

Synchronisation ist damit mehr als regelmäßiges Kopieren. Sie setzt eine Festlegung voraus, anhand welcher Informationen Änderungen erkannt werden und welcher Zustand im Konfliktfall gilt. 

Tiering bewegt Daten nach Regeln zwischen Storage-Klassen 

Storage Tiering verfolgt wiederum ein anderes Ziel. Die SNIA definiert Automated Storage Tiering als automatische Bewegung von Daten zwischen Storage Tiers auf Basis von Policies. Diese Tiers können sich über unterschiedliche Storage-Systeme erstrecken, einschließlich eines Cloud Storage Tier. 

Typisch ist deshalb keine vollständige Kopie eines Systems auf ein zweites, sondern eine regelgesteuerte Bewegung einzelner Datenelemente zwischen einem schnellen Tier und einem Kapazitäts- oder Cloud-Tier. Welche Daten bewegt werden, hängt etwa von Zugriffsmustern oder anderen definierten Kriterien ab. Die SNIA beschreibt Tiered Storage entsprechend als mehrere Storage-Klassen, zwischen denen Daten abhängig von Zugriff oder anderen Kriterien verschoben werden. 

Für Anwendungen und Benutzer stellt sich zusätzlich die Frage, wie ausgelagerte Daten wieder verfügbar werden und wie stark ein Recall die Zugriffszeit verändert.

Backup bewegt Daten mit Recovery-Zweck 

Auch Backup bewegt Daten, verfolgt damit aber die spätere Wiederherstellung. Entscheidend sind deshalb nicht nur Transfereigenschaften, sondern die verfügbaren Wiederherstellungspunkte, die aufbewahrten Datenstände, der Schutz der Sicherungen, der Rückweg der Daten und die Frage, ob eine Wiederherstellung tatsächlich getestet wurde. 

NIST SP 800-209 behandelt Backup und Replication als Bestandteile der Data Protection von Storage-Infrastrukturen und führt in der finalen Fassung von 2020 unter anderem Restoration Assurance als eigenes Sicherheitsfeld. 

3. Die Datenmenge liefert nur die theoretische Untergrenze

Die Überschlagsrechnung beschreibt einen Idealfall 

Für einen ersten Überschlag lässt sich die minimale Übertragungszeit aus Datenmenge und effektivem Durchsatz berechnen. Bei einer idealisierten Verbindung mit 1 Gbit/s ergeben sich für 1 TB dezimal 8.000 Gbit und damit 8.000 Sekunden, also rund 2,2 Stunden. 

Dieser Wert ist eine theoretische Untergrenze bei kontinuierlicher vollständiger Auslastung. Er berücksichtigt weder Protokoll-Overhead noch Paketverluste, konkurrierenden Verkehr, Verarbeitungszeiten oder Limits der beteiligten Systeme. 

Der gesamte Pfad begrenzt den Durchsatz, nicht der Anschluss 

Zwischen Storage-Quelle und Storage-Ziel liegt ein vollständiger Datenpfad aus Quellsystem, Transferkomponente, LAN, WAN, Cloud-Endpunkt und Storage-Dienst. Jede Stufe kann zum begrenzenden Faktor werden. 

Sechs Stufen vom Quellsystem bis zum Storage-Dienst, darunter jeweils der typische Engpass von der Leserate bis zur Ingest-Rate.

Auf TCP-basierten Verbindungen wirken zusätzlich Transportmechanismen auf den erreichbaren Durchsatz. RFC 6349 beschreibt unter anderem den Zusammenhang zwischen Round-Trip Time, Bottleneck Bandwidth, Bandwidth-Delay Product sowie TCP Send- und Receive Windows. RFC 5166 behandelt Durchsatz, Delay und Paketverluste als miteinander verbundene Metriken für CongestionControl. 

Eine hohe Bandbreite lässt sich über größere Distanzen deshalb nur nutzen, wenn der gesamte Übertragungspfad dafür ausgelegt ist. Praktisch relevant sind die tatsächlich verfügbare Bandbreite, Round-Trip Time und Paketverluste, die Anzahl paralleler Transfers, das Verhalten von TCP und Anwendung, die Leserate des Quellsystems, die Ingest-Rate des Zielsystems, der CPU-Aufwand für Verschlüsselung und Prüfsummen sowie API- und Service-Limits. 

Eine Messung sollte deshalb den vollständigen Pfad einbeziehen und nicht bei einem isolierten Bandbreitentest stehen bleiben. 

4. Viele kleine Dateien sind ein anderer Workload als wenige große 

Zwei Datenbestände mit jeweils 10 TB verhalten sich beim Transfer nicht zwangsläufig gleich. Der eine kann aus wenigen sehr großen Dateien bestehen, der andere aus Millionen kleiner. 

Große, sequenziell übertragene Datenobjekte erzeugen lange Datenströme. Bei sehr vielen kleinen Dateien fallen dagegen ungleich häufiger Operationen für Dateizugriff, Metadaten, Namespace-Verarbeitung, Protokolltransaktionen und die Erzeugung von Zielobjekten an. 

Eine Migrationsplanung sollte deshalb zwei Größen getrennt betrachten: das Datenvolumen und die Anzahl beziehungsweise Größenverteilung der Datenelemente. 

In Projekten sehen wir regelmäßig, dass ein Durchsatztest mit wenigen großen Testdateien einen Produktionsbestand aus sehr vielen kleinen Dateien nicht repräsentativ abbildet. Wir behandeln die Vorab-Analyse der Größenverteilung deshalb als Pflichtbestandteil der Planung. 

5. Die Änderungsrate entscheidet, ob eine Migration aufholen kann 

Bei einem statischen Archiv bleibt die Datenmenge weitgehend konstant. Bei aktiven Fileservices, Datenbanken oder anderen produktiven Systemen entstehen während des Transfers laufend neue Änderungen. 

Vereinfacht lässt sich die Lage als Verhältnis zweier Größen beschreiben: der erreichbaren Transferleistung und der Änderungsrate. Damit ein nachgelagerter Delta-Abgleich einen Rückstand abbauen kann, muss die dauerhaft erreichbare Transferleistung unter sonst gleichen Bedingungen größer sein als die Datenmenge, die pro Zeiteinheit nachzuführen ist.  

Zwei Kurven über der Zeit: Der Rückstand konvergiert nur, wenn die Transferleistung über der Änderungsrate liegt.

Bleibt die Übertragungsleistung unter der Änderungsmenge, konvergiert der Rückstand durch kontinuierlichen Delta-Transfer nicht. Darin liegt der wesentliche Unterschied zwischen der Migration eines statischen Datenbestands und der eines produktiv genutzten Systems. 

6. Deshalb wird Datenbewegung in Phasen zerlegt 

Eine verbreitete Strategie gliedert die Datenbewegung in aufeinanderfolgende Phasen. Zunächst wird der Großteil des vorhandenen Bestands übertragen. Währenddessen werden Änderungen an der Quelle erfasst. Nach dem Initialtransfer folgen nur noch die seitdem entstandenen Änderungen. Kurz vor dem Cutover wird der verbleibende Unterschied minimiert oder vollständig abgeglichen. Erst danach wechseln Anwendungen und Benutzer auf das Zielsystem.

Zeitachse mit Initial Copy, Delta Transfer, Final Sync und Cutover, parallelem Change Tracking und schrumpfendem offenen Delta.

Das zugrunde liegende Prinzip, den vollständigen Datenbestand nicht erneut übertragen zu müssen, lässt sich unterschiedlich umsetzen. Ein bekanntes Beispiel auf Dateiebene ist der rsync-Algorithmus. Er identifiziert Bereiche einer Quelldatei, die auf der Gegenseite bereits vorliegen, und überträgt im Wesentlichen die abweichenden Datenbereiche. Der ursprüngliche technische Bericht von 1996 beschreibt das Verfahren ausdrücklich für Verbindungen mit geringer Bandbreite und hoher Latenz. 

Daraus folgt jedoch nicht, dass jedes Cloud-Migrationswerkzeug rsync verwendet. Delta-Verfahren arbeiten auf Datei-, Block-, Objekt-, Journal- oder Applikationsebene und besitzen entsprechend unterschiedliche Eigenschaften. 

7. Offline ist nicht automatisch schneller als online 

Daten müssen nicht vollständig über eine WAN-Verbindung transportiert werden. Grundsätzlich stehen zwei Modelle zur Wahl. 

Online-Transfer nutzt den direkten Datenpfad 

Die Daten werden über eine Netzwerkverbindung direkt zum Ziel übertragen. Vorteile sind der direkte Pfad und die Möglichkeit, Erst- und Delta-Läufe ohne physischen Transport durchzuführen. Die praktische Grenze ergibt sich aus dem verfügbaren End-to-End-Durchsatz und dem Transferfenster. 

Offline-Transfer verlagert den Engpass in die Logistik 

Bei sehr großen Datenbeständen lässt sich ein physisches Transfersystem einsetzen. Die Daten werden lokal auf eine Appliance kopiert, diese wird zum Anbieter transportiert und ihr Inhalt dort in den Cloud-Storage importiert. 

Dass dieses Modell nicht nur theoretisch existiert, zeigt die dokumentierte Transfer-Appliance-Architektur von Google Cloud. Sie beschreibt einen Offline- und einen Online-Modus: Im Offline-Modus werden Daten auf die Appliance kopiert, die Appliance anschließend an den Anbieter zurückgesendet und die Daten dort in den Ziel-Bucket übertragen. Im Online-Modus werden die auf die Appliance kopierten Daten stattdessen direkt in den Ziel-Bucket gestreamt. Das Beispiel dient als Nachweis des technischen Verfahrens, nicht als Produktempfehlung. 

Offline bedeutet dabei nicht schneller. Der reinen Übertragungszeit über das Netzwerk steht auf dem Offline-Weg die Summe aus lokaler Kopierzeit, Versand und Logistik, Importzeit und gegebenenfalls einem anschließenden Delta-Abgleich gegenüber. 

Ein Offline-Seed löst zudem das Problem laufender Änderungen nicht. Verändert sich die Quelle während Transport und Import weiter, bleibt anschließend eine Online-Synchronisation der Deltas erforderlich. 

8. Erst die Konsistenzprüfung beendet eine Migration 

Eine erfolgreiche Datenübertragung bedeutet noch nicht, dass Quelle und Ziel denselben nutzbaren Zustand besitzen. 

Nach einem Transfer sind deshalb Validierungen erforderlich. Geprüft werden je nach Umgebung die Anzahl der Dateien oder Objekte, Größen, Prüfsummen, Metadaten, Zeitstempel, Verzeichnis- oder Namespace-Strukturen, Zugriffsrechte und die Applikationskonsistenz. Welche dieser Eigenschaften zählen, hängt von Quelle, Ziel, Protokoll und Anwendung ab. 

Gerade beim Wechsel zwischen unterschiedlichen Storage-Modellen lässt sich nicht voraussetzen, dass jede Eigenschaft der Quelle im Ziel eine direkte Entsprechung besitzt. 

Die CDMI-Spezifikation adressiert unter anderem Daten, Container, Metadaten und Data Portability. Die SNIA beschreibt CDMI darüber hinaus als Ansatz zur Datenbewegung zwischen Systemen unter Erhaltung von Struktur, Inhalt und Cross-Protocol-Metadaten. Bei einer konkreten Migration bleibt dennoch zu prüfen, welche Eigenschaften die tatsächlich eingesetzten Quell- und Zielsysteme sowie die verwendeten Transferwerkzeuge unterstützen. 

9. Der Transferpfad ist ein zusätzlicher Angriffspfad 

Ein Transfer schafft einen zusätzlichen Datenpfad zwischen administrativen Domänen. Authentifizierung, Autorisierung, Verschlüsselung, Zugangsdaten und Protokollierung gehören deshalb zur Planung der Datenbewegung. 

NIST SP 800-209 nennt für Storage-Infrastrukturen in der Fassung von 2020 unter anderem Authentication and Authorization, Data Protection, Isolation, Restoration Assurance und Encryption als relevante Sicherheitsbereiche. 

Bei einer Migration ist deshalb nicht nur zu prüfen, ob die Daten angekommen sind, sondern auch, wer den Transfer initiieren durfte, welche Identität auf Quelle und Ziel zugreift, wie Daten während der Übertragung geschützt sind, welche Berechtigungen die Transferkomponente besitzt und wie erfolgreiche wie fehlgeschlagene Transfers nachvollziehbar bleiben. 

Transferwerkzeuge benötigen häufig weitreichenden Zugriff auf Quelle und Ziel. Wir behandeln diese Berechtigungen deshalb als Bestandteil des Sicherheitsdesigns und nicht als Nebenaspekt der Werkzeugauswahl. 

10. Der Rückweg gehört in dieselbe Planung 

Eine Cloud-Migration sollte nicht allein als Weg von On-Premises in die Cloud betrachtet werden. Je nach Architektur sind später große Datenmengen in Gegenrichtung zu bewegen, etwa zurück in das eigene Rechenzentrum oder über eine lokale Zwischenstufe zu einem anderen Anbieter. 

Technisch zählen dann erneut Bandbreite, Transferdauer, Protokolle, Datenformat und Kompatibilität. Hinzu kommen die Kostenmodelle der eingesetzten Cloud-Dienste. 

Gebühren für Datenübertragung, API-Aufrufe oder andere Operationen sind keine allgemeine Eigenschaft der Cloud. Sie sind für den jeweiligen Anbieter, Dienst, die Region und das Vertragsmodell einzeln zu prüfen. 

Die technische Exit-Fähigkeit einer Architektur sollte deshalb nicht erst dann untersucht werden, wenn ein Anbieterwechsel bereits beschlossen ist. 

11. Welches Verfahren zu welchem Ziel passt 

Diese Mechanismen lassen sich kombinieren. Eine Cloud-Migration kann mit einem Initial Seed beginnen, anschließend Änderungen replizieren und beim Cutover einen finalen Delta-Abgleich durchführen. 

Ziel

Datenbestand einmalig verlagern
  

Zweite aktuelle Kopie betreiben
  

Datenbestände laufend abgleichen  

Daten nach Policies verlagern
 

Wiederherstellbare Kopien erzeugen 

Sehr große Erstbefüllung 

Typischer Mechanismus

 Migration
 

Replikation
 

Synchronisation 
 

Tiering
 

Backup 
 

Online- oder Offline-Seed 

Zentrale technische Frage

Wie werden Änderungen während des Transfers nachgeführt? 

Welches RPO und welche Konsistenz werden benötigt? 

Wie werden Änderungen und Konflikte erkannt? 

Wann werden Daten verschoben und wie erfolgt der Recall? 

Welche Recovery Points und welches RTO werden benötigt? 

Welcher End-to-End-Weg erreicht das erforderliche Transferfenster? 

12. Welche Größen vor der Entscheidung bekannt sein müssen 

Erst aus der Kombination dieser Größen lässt sich beurteilen, welches Verfahren trägt. Der Datenpfad zwischen Cloud und On-Premises ist damit kein nachgelagertes Migrationsthema, sondern Bestandteil der Architektur.

Parameter

Datenvolumen 

Anzahl Dateien und Objekte 

Größenverteilung  

Änderungsrate  

Verfügbare Bandbreite  

Gemessener End-to-End-Durchsatz  

RTT und Netzwerkqualität  

Transferfenster  

Quellperformance  

Zielperformance und API-Limits  

Metadaten und Berechtigungen  

Konsistenzanforderungen  

Rücktransfer  

Bedeutung

 Umfang des Initialtransfers 

Anzahl zu verarbeitender Einheiten 

Verhältnis kleiner zu großen Datenelementen 

Nach dem Initialtransfer nachzuführende Datenmenge 

Obere Netzwerkgrenze 

Realistische Grundlage der Zeitplanung 

Einfluss auf Transport- und Protokollverhalten 

Verfügbare Zeit für die Übertragung 

Erreichbare Leserate 

Erreichbare Ingest-Rate 

Zusätzlich zu übertragende Semantik 

Zulässiger Unterschied zwischen Quelle und Ziel 

Technische und wirtschaftliche Exit-Fähigkeit 

13. Fazit 

Daten zwischen On-Premises und Cloud zu bewegen ist mehr als die Übertragung einer bestimmten Anzahl von Terabytes. 

Zuerst ist zu klären, ob eine Migration, eine Replikation, eine Synchronisation, ein Tiering oder ein Backup benötigt wird. Danach bestimmen Datenvolumen, Dateianzahl und Größenverteilung, Änderungsrate, Bandbreite, Latenz, Quell- und Zielperformance sowie Konsistenzanforderungen den geeigneten technischen Ansatz. 

Für große statische Datenbestände genügt womöglich ein einmaliger Online- oder Offline-Transfer. Bei produktiv veränderten Beständen wird dagegen häufig ein mehrstufiges Verfahren aus Initialtransfer, Change Tracking, Delta-Transfer, Validierung und Cutover erforderlich. 

Die zentrale Planungsgröße ist deshalb nicht, wie viele Daten vorhanden sind, sondern wie schnell sich ein konsistenter Datenbestand überführen lässt, während die Quelle sich weiter verändert, und ob derselbe Datenpfad im Bedarfsfall auch in Gegenrichtung trägt. 

14. Quellen

ISO/IEC: ISO/IEC 17826:2022 — Information technology — Cloud Data Management Interface (CDMI) Version 2.0.0, Edition 3, Mai 2022. ISO/IEC 17826:2022 (abgerufen am 07.09.2026) 

Storage Networking Industry Association (SNIA): Cloud Data Management Interface (CDMI), Informationen zum Standard und zu Data Portability. SNIA — Cloud Data Management Interface (abgerufen am 07.09.2026) 

SNIA: Data Replication, Synchronous Replication, Asynchronous Replication, Continuous Data Protection, Automated Storage Tiering und Tiered Storage, SNIA Dictionary. SNIA Dictionary (abgerufen am 07.09.2026) 

Ramaswamy Chandramouli, Doron Pinhas / National Institute of Standards and Technology: Security Guidelines for Storage Infrastructure, NIST Special Publication 800-209, Oktober 2020, DOI 10.6028/NIST.SP.800-209. Finale Fassung; auf diese Fassung wird im Artikel ausdrücklich Bezug genommen. NIST SP 800-209 (abgerufen am 07.09.2026) 

Ramaswamy Chandramouli / National Institute of Standards and Technology: Security Guidelines for Storage Infrastructure, NIST SP 800-209 Rev. 1, Initial Public Draft, 22. Juli 2026, DOI 10.6028/NIST.SP.800-209r1.ipd. Entwurfsstatus; Kommentierungsfrist bis 08.09.2026. NIST SP 800-209 Rev. 1 ipd (abgerufen am 07.09.2026) 

Andrew Tridgell, Paul Mackerras / Australian National University: The rsync algorithm, Technical Report TR-CS-96-05, Department of Computer Science, Canberra, Juni 1996. The rsync algorithm (abgerufen am 07.09.2026) 

B. Constantine, G. Forget, R. Geib, R. Schrage / IETF: RFC 6349 — Framework for TCP Throughput Testing, August 2011. RFC 6349 (abgerufen am 07.09.2026) 

S. Floyd (Ed.) / IETF: RFC 5166 — Metrics for the Evaluation of Congestion Control Mechanisms, März 2008. RFC 5166(abgerufen am 07.09.2026) 

Google Cloud: Transfer Appliance — High-level overview, Produktdokumentation Version 4.0; als Implementierungsbeispiel für physische und netzbasierte Datentransfers. Transfer Appliance — Overview (abgerufen am 07.09.2026) 

 

Welche Entscheidung steht bei Ihnen an?

Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.

Spezialist für moderne Dateninfrastruktur

Information icon

Wir benötigen Ihre Zustimmung zum Laden der Übersetzungen

Wir nutzen einen Drittanbieter-Service, um den Inhalt der Website zu übersetzen, der möglicherweise Daten über Ihre Aktivitäten sammelt. Bitte überprüfen Sie die Details in der Datenschutzerklärung und akzeptieren Sie den Dienst, um die Übersetzungen zu sehen.