Diese Seite wurde von der Cloud Translation API übersetzt.

Datenvalidierung und Änderungserkennung

Mit Cloud Storage können Sie die Daten validieren, die Sie zu und aus 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 Änderungserkennung beschrieben, der vom Befehl gcloud storage rsync verwendet wird.

Vor Datenbeschädigung durch Hashes schützen

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

Fehler im Arbeitsspeicher des Client- oder Servercomputers oder eines Routers entlang des Pfads
Softwarefehler, z. B. in einer von den 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 MD5 bevorzugen, können diesen Hash verwenden. MD5-Hashes werden für alle Objekte jedoch nicht unterstützt.

Clientseitige Validierung

Sie können eine Integritätsprüfung für heruntergeladene Daten durchführen, indem Sie die Daten direkt in einen Hash umwandeln und die Ergebnisse mit den vom Server bereitgestellten Prüfsummen vergleichen. Die vom Server bereitgestellten Prüfsummen basieren jedoch auf dem vollständigen Objekt, wie es in Cloud Storage gespeichert ist. Das bedeutet, dass die folgenden Downloadtypen nicht mit den vom Server bereitgestellten Hash-Werten validiert werden können:

Downloads, die einer dekomprimierenden Transcodierung unterzogen werden, da die vom Server bereitgestellte Prüfsumme das Objekt in seinem komprimierten Zustand darstellt, während die bereitgestellten Daten ohne Komprimierung gesendet wurden und daher ein anderer Hash-Wert vorhanden ist.
Eine Antwort, die nur einen Teil der Objektdaten enthält. Das kann bei einer range-Anfrage vorkommen. Für Cloud Storage wird deshalb empfohlen, Anfragebereiche nur für den Neustart des Downloads eines kompletten Objekts nach dem letzten erhaltenen Versatz zu verwenden. In diesem Fall können Sie die Prüfsumme berechnen und validieren, wenn der vollständige Download abgeschlossen ist.

Wenn Sie den Download mithilfe von Prüfsummen validieren können, sollten Sie heruntergeladene Daten mit falschen Hash-Werten verwerfen und die empfohlene Wiederholungslogik verwenden, um die Anfrage noch einmal zu versuchen.

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.
Wenn Sie den erwarteten MD5- oder CRC32C-Hash eines Objekts in einer Uploadanfrage angeben. Cloud Storage erstellt das Objekt nur, wenn der Hash mit dem Wert übereinstimmt, den Cloud Storage berechnet. Andernfalls wird die Anfrage mit dem Fehler BadRequestException: 400 abgelehnt.
- In entsprechenden JSON API-Anfragen geben Sie Prüfsummen als Teil der Ressource „objects“ an.
- In entsprechenden XML API-Anfragen geben Sie Prüfsummen mit dem Header x-goog-hash 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, sodass ein Abgleich mit dem erwarteten Wert erfolgt und das Objekt im Fall einer Nichtübereinstimmung gelöscht wird. Diese Methode ist nützlich, wenn der MD5- oder CRC32C-Hash des Objekts nicht zu Beginn des Uploads bekannt ist.

Bei parallelen zusammengesetzten Uploads sollten Nutzer für den Upload jeder Komponente eine Integritätsprüfung durchführen und anschließend bei ihren Zusammensetzungsanfragen Vorbedingungen für die Komponenten verwenden, um diese vor Race-Bedingungen zu schützen. Bei Zusammenstellungsanfragen wird keine serverseitige Validierung durchgeführt. Nutzer, die eine End-to-End-Integritätsprüfung wünschen, sollten deshalb eine clientseitige Validierung für das neue zusammengesetzte Objekt durchführen.

Google Cloud CLI-Validierung

Bei der Google Cloud CLI werden Daten, die in einen Cloud Storage-Bucket oder aus einem solchen 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 nur sehr selten. Sollte dieser Fall eintreten, sollten Sie versuchen, den Vorgang zu wiederholen.

Diese automatische Validierung erfolgt, nachdem das Objekt selbst fertiggestellt wurde. Ungültige Objekte sind also 1–3 Sekunden lang sichtbar, bevor sie erkannt und gelöscht werden. Außerdem besteht die Möglichkeit, dass die gcloud CLI nach Abschluss des Uploads, aber vor der Validierung unterbrochen wird, sodass das ungültige Objekt nicht entfernt wird. Diese Probleme können beim Hochladen einzelner Dateien in Cloud Storage mithilfe der serverseitigen Validierung vermieden werden, die bei Verwendung des Flags --content-md5 erfolgt.

Änderungserkennung für `rsync`

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

Sowohl Quelle als auch Ziel sind Cloud-Buckets und das Objekt hat in beiden Buckets eine MD5- oder CRC32C-Prüfsumme.
Das Objekt hat weder in der Quelle noch im Ziel eine Dateiänderungszeit (mtime).

Wenn das betreffende 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 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 Zeit als Ersatz für mtime und der Befehl verwendet 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.