Datenvalidierung und Änderungserkennung

Cloud Storage bietet die Möglichkeit, die Daten zu validieren, die Sie zu und von Ihren Buckets übertragen. Auf dieser Seite werden Best Practices für Validierungen mit CRC32C- oder MD5-Prüfsummen erläutert. Außerdem wird der Algorithmus zur Erkennung von Änderungen beschrieben, den der gcloud storage rsync-Befehl nutzt.

Vor Datenbeschädigung durch Hashes schützen

Es gibt eine Vielzahl von Möglichkeiten, wie Daten beim Hochladen in die Cloud oder beim Herunterladen daraus beschädigt werden können:

Fehler im Arbeitsspeicher des Client- oder Servercomputers oder eines Routers entlang des Pfads
Softwarefehler, z. B. in einer von Kunden verwendeten Bibliothek
Änderungen an der Quelldatei, wenn ein Upload über einen längeren Zeitraum erfolgt

Cloud Storage unterstützt zwei Arten von Hashes, mit denen Sie die Integrität Ihrer Daten prüfen können: CRC32C und MD5. CRC32C ist die empfohlene Validierungsmethode für Integritätsprüfungen. Kunden, die lieber MD5 nutzen, können diesen Hash verwenden. MD5-Hashes werden jedoch nicht für alle Objekte unterstützt.

Clientseitige Validierung

Sie können die Integrität heruntergeladener Daten prüfen, indem Sie die Daten direkt in einen Hashwert umwandeln und die Ergebnisse mit den vom Server übergebenen Prüfsummen vergleichen. Die vom Server bereitgestellten Prüfsummen basieren jedoch auf dem vollständigen Objekt, so wie es in Cloud Storage gespeichert ist. Das bedeutet, dass die folgenden Arten von Downloads nicht mit den vom Server bereitgestellten Hashes validiert werden können:

Downloads, die eine dekomprimierende Transcodierung durchlaufen, da die vom Server bereitgestellte Prüfsumme für das Objekt im komprimierten Zustand gilt, während die bereitgestellten Daten ohne Komprimierung gesendet wurden und daher einen anderen Hashwert ergeben.
Eine Antwort, die nur einen Teil der Objektdaten enthält. Dies ist bei einer range-Anfrage der Fall. Cloud Storage empfiehlt, Anfragebereiche nur für den Neustart des Downloads eines vollständigen Objekts nach dem letzten empfangenen Versatz zu verwenden. In diesem Fall können Sie die Prüfsumme berechnen und validieren, wenn der komplette Download abgeschlossen ist.

Wenn Sie den Download mit Prüfsummen validieren können, sollten Sie heruntergeladene Daten mit falschen Hashwerten verwerfen und mit der empfohlenen Wiederholungslogik die Anfrage noch einmal senden.

Serverseitige Validierung

In folgenden Fällen führt Cloud Storage eine serverseitige Validierung durch:

Wenn Sie eine Kopier- oder Umschreibungsanfrage in Cloud Storage ausführen.
- Die serverseitige Validierung wird von Cloud Storage automatisch anhand einer nicht bearbeitbaren Prüfsumme ausgeführt, die mit dem Quellobjekt gespeichert ist.
Wenn Sie den erwarteten MD5- oder CRC32C-Hashwert eines Objekts in einer Uploadanfrage angeben. Cloud Storage erstellt das Objekt nur, wenn der bereitgestellte Hashwert mit dem Wert übereinstimmt, den Cloud Storage berechnet. Stimmt er nicht über, wird die Anfrage mit dem Fehler BadRequestException: 400 abgelehnt.
- In entsprechenden JSON API-Anfragen geben Sie Prüfsummen als Teil der Objektressource an.
- In entsprechenden XML-API-Anfragen geben Sie Prüfsummen mit dem x-goog-hash-Header an. Die XML-API akzeptiert auch den standardmäßigen HTTP-Header Content-MD5 (siehe Spezifikation).
- Alternativ können Sie eine clientseitige Validierung Ihrer Uploads durchführen, indem Sie eine Anfrage für die Metadaten des hochgeladenen Objekts stellen, den Hashwert des hochgeladenen Objekts mit dem erwarteten Wert vergleichen und das Objekt im Falle einer fehlenden Übereinstimmung löschen. Diese Methode ist hilfreich, wenn der MD5- oder CRC32C-Hashwert des Objekts zu Beginn des Uploads nicht bekannt ist.

Bei parallelen zusammengesetzten Uploads sollten Nutzer für den Upload jeder einzelnen Komponente eine Integritätsprüfung durchführen und anschließend bei ihren Anfragen zur Zusammensetzung Vorbedingungen verwenden, um diese vor Race-Bedingungen zu schützen. Bei Anfragen zur Zusammensetzung erfolgt keine serverseitige Validierung. Nutzer, die eine End-to-End-Integritätsprüfung ausführen möchten, sollten deshalb für das neue zusammengesetzte Objekt eine clientseitige Validierung verwenden.

Google Cloud CLI-Validierung

Bei der Google Cloud CLI werden Daten, die in einen Cloud Storage-Bucket oder aus einem Cloud Storage-Bucket kopiert werden, validiert. Das gilt für die Befehle cp, mv und rsync. Wenn die Prüfsumme der Quelldaten nicht mit der Prüfsumme der Zieldaten übereinstimmt, löscht die gcloud CLI die ungültige Kopie und gibt eine Warnmeldung aus. Dies geschieht aber nur sehr selten. Wenn dieser Fall eintritt, sollten Sie versuchen, den Vorgang zu wiederholen.

Diese automatische Validierung erfolgt, nachdem das Objekt selbst fertiggestellt wurde. Ungültige Objekte sind also 1 bis 3 Sekunden lang sichtbar, bevor sie erkannt und gelöscht werden. Außerdem besteht die Möglichkeit, dass die gcloud CLI nach dem Upload, aber vor der Validierung unterbrochen wird, sodass das ungültige Objekt erhalten bleibt. Diese Probleme lassen sich beim Hochladen einzelner Dateien in Cloud Storage vermeiden, wenn Sie die serverseitige Validierung nutzen. Diese wird bei Verwendung des Flags --content-md5 ausgeführt.

Erkennung von Änderungen für `rsync`

Mit dem Befehl gcloud storage rsync können MD5- oder CRC32C-Prüfsummen auch verwendet werden, um festzustellen, ob es einen Unterschied zwischen der Version eines Objekts in der Quelle und der Version im Ziel gibt. Der Befehl vergleicht Prüfsummen in den folgenden Fällen:

Sowohl die Quelle als auch das Ziel sind Cloud-Buckets und das Objekt hat in beiden Buckets eine MD5- oder CRC32C-Prüfsumme.
Für das Objekt ist weder in der Quelle noch im Ziel eine Änderungszeitangabe für die Datei (mtime) vorhanden.

Wenn das relevante Objekt sowohl in der Quelle als auch im Ziel einen mtime-Wert hat, z. B. wenn Quelle und Ziel Dateisysteme sind, vergleicht der Befehl rsync die Größe und den mtime-Wert der Objekte, anstatt Prüfsummen zu verwenden. Wenn die Quelle ein Cloud-Bucket und das Ziel ein lokales Dateisystem ist, verwendet der Befehl rsync die für das Quellobjekt erstellte Zeitangabe als Ersatz für mtime und der Befehl nutzt keine Prüfsummen.

Wenn weder mtime noch Prüfsummen verfügbar sind, vergleicht rsync nur die Dateigrößen, um festzustellen, ob sich die Quellversion eines Objekts von der Zielversion unterscheidet. Zum Beispiel sind weder mtime noch Prüfsummen verfügbar, wenn Sie zusammengesetzte Objekte mit Objekten bei einem Cloud-Anbieter vergleichen, der CRC32C nicht unterstützt, da zusammengesetzte Objekte kein MD5-Prüfsummen haben.