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 Erkennung von Änderungen beschrieben, der vom gcloud storage rsync-Befehl 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 die Integrität heruntergeladener Daten prüfen, indem Sie die Daten in einen Hash umwandeln und Ihre 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 Arten von Downloads nicht mit den vom Server bereitgestellten Hashes validiert werden können:

Downloads, die dekomprimierende Transcodierung durchlaufen, da die vom Server bereitgestellte Prüfsumme das Objekt im 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, was bei einer range-Anfrage der Fall ist. 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 mit 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 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.
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. Wenn sie nicht übereinstimmt, 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 Hash-Wert des hochgeladenen Objekts mit dem erwarteten Wert vergleichen und das Objekt im Fall einer Nichtübereinstimmung löschen. 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 Compose-Anfragen wird keine serverseitige Validierung durchgeführt. Nutzer, die eine End-to-End-Integritätsprüfung durchführen möchten, sollten deshalb eine clientseitige Validierung für das neue zusammengesetzte Objekt verwenden.

Google Cloud CLI-Validierung

Bei der Google Cloud CLI werden Daten, die in einen Cloud Storage-Bucket kopiert 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 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 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 verwenden, die beim Verwenden 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 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.
Das Objekt hat weder in der Quelle noch im Ziel eine Änderungszeit für die Datei (mtime).

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