Google-Drive-Störung: Kein Zugriff auf Dateien in Australien, Neuseeland und auf den Philippinen
Eine Google-Drive-Störung hat vom 18. bis 19. August 2026 regional den Zugriff auf Dateien blockiert: 12 Stunden und 42 Minuten lang meldeten Nutzer in Australien, Neuseeland und auf den Philippinen extreme Ladezeiten, 502-Fehler und zeitweise gar keinen Zugang. Ursache war laut Google eine Fehlkonfiguration im Netzwerk-Routing – kein Datenverlust, kein Gerätedefekt.
Für Betroffene fühlte sich das trotzdem an wie ein Totalausfall: Dokumente ließen sich nicht öffnen, Dateilisten in Google Editors – also den Web-Anwendungen wie Docs, Tabellen und Präsentationen unter docs.google.com – luden minutenlang oder brachen mit Fehlermeldung ab. Wer in dieser Zeit an einer Präsentation, einer Abrechnung oder einem Angebot arbeiten musste, stand still.
Der entscheidende Punkt für alle, die jetzt nach „Google Drive Störung kein Zugriff auf Dateien“ suchen: Die Daten selbst lagen nach Googles Darstellung unverändert in der Cloud. Gefährlich wurde es erst dort, wo Nutzer während oder nach der Störung anfingen, an lokalen Kopien, Synchronisationseinstellungen oder Offline-Dateien herumzuschrauben.
Was genau ist passiert?
Google dokumentiert den Vorfall im eigenen Workspace Status Dashboard. Beginn war am 18. August 2026 um 16:58 US/Pacific (23:58 UTC), das Ende meldete Google für den 19. August 2026 um 05:40 US/Pacific (12:40 UTC). Die offizielle Dauer: 12 Stunden und 42 Minuten.
Betroffen waren ausschließlich Google-Drive-Kunden in drei Ländern: Australien, den Philippinen und Neuseeland. Andere Google-Workspace-Dienste blieben nach Angaben des Unternehmens funktionsfähig:
„Other Google Workspace services were not affected.“
– Google Workspace Status Dashboard, vorläufiger Incident Report (Quelle)
Die Ursache lag nicht in einer defekten Datei, einer fehlerhaften App-Version oder einem kaputten Endgerät, sondern tief in Googles eigener Infrastruktur. In der mehrstufigen globalen Lastverteilung ordnet Google den Datenverkehr den jeweils nachgelagerten Diensten zu, um Bandbreiten zu steuern. Genau diese Zuordnung war falsch konfiguriert:
„A misconfiguration in the attribution of traffic caused the bandwidth usage to be incorrectly attributed to the frontend network load balancing tier itself, rather than to the Drive service.“
– Google Workspace Status Dashboard, vorläufiger Incident Report (Quelle)
Die Folge: Fremder, mit Drive gar nicht zusammenhängender Datenverkehr sprengte das Kontingent, das dieser Ebene zugerechnet wurde. Die Bandbreitensteuerung drosselte daraufhin den Verkehr – und der regionale Netzpfad für Google Drive war massiv überlastet. Das erklärt die Symptomkombination aus Latenz, Timeouts und 502-Fehlern.
Was bedeutet ein 502-Fehler eigentlich?
Der HTTP-Statuscode 502 („Bad Gateway“) ist eine Server-, keine Gerätemeldung. Die zuständige Standardisierungsgruppe beschreibt ihn so:
„The 502 (Bad Gateway) status code indicates that a server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed in attempting to fulfill the request.“
– IETF HTTP Working Group, RFC 9110, Abschnitt 15.6.3 (Quelle)
Im Klartext: Ein Zwischenserver hat von einem dahinterliegenden Server eine ungültige Antwort bekommen. Ein 502-Fehler ist kein Beweis dafür, dass eine Datei beschädigt oder eine Festplatte, SSD oder ein Notebook defekt ist. Genau diese Fehldeutung führt allerdings regelmäßig zu voreiligen „Reparaturversuchen“ am eigenen Gerät – mit Folgen, die schlimmer sind als der ursprüngliche Ausfall.
Wer und welche Geräte sind betroffen?
Google hat keine Zahl betroffener Nutzer, Geräte oder Organisationen veröffentlicht. Ebenso wenig gibt es eine Abhängigkeit von einem bestimmten Betriebssystem, einer App-Version, einem Browser, einer Gerätereihe oder einem Firmwarestand. Konkret dokumentiert sind:
- Dienst: Google Drive sowie das Auflisten von Dateien in Google Editors (z. B. docs.google.com)
- Regionen: Australien, Philippinen, Neuseeland
- Zeitfenster: 18. August 2026, 23:58 UTC bis 19. August 2026, 12:40 UTC
- Nicht betroffen: die übrigen Google-Workspace-Dienste
Für deutsche Nutzer heißt das: Wer in diesem Zeitraum in Europa gearbeitet hat, war von diesem Vorfall nicht betroffen. Relevant ist der Fall dennoch – für Unternehmen mit Standorten oder Partnern im asiatisch-pazifischen Raum, für Reisende, und als Lehrstück darüber, was ein Cloud-Ausfall mit lokal synchronisierten Datenbeständen anrichten kann.
Woran Sie eine Google-Drive-Störung erkennen
- Drive lädt extrem langsam, die initiale Ladezeit zieht sich ungewöhnlich lange hin.
- Beim Zugriff erscheint ein HTTP-502-Fehler; Drive ist zeitweise gar nicht aufrufbar.
- In Google Editors (docs.google.com) lässt sich die Dateiliste nicht oder nur stark verzögert anzeigen.
So prüfen Sie, ob Sie betroffen sind – ohne etwas zu riskieren
Alle folgenden Schritte sind rein prüfend und lesend. Sie verändern nichts an Ihren Daten:
- Status Dashboard aufrufen. Öffnen Sie den historischen Eintrag im Google Workspace Status Dashboard und gleichen Sie Land, Uhrzeit und Symptome mit dem Vorfall vom 18. bis 19. August 2026 ab. Der bestätigte Zeitraum endet am 19. August um 05:40 US/Pacific bzw. 12:40 UTC.
- Bei aktuellen 502-Fehlern kurz warten. Google verweist bei einem temporären 502-Fehler ausdrücklich auf das Dashboard und empfiehlt, den Abruf nach kurzer Zeit erneut zu versuchen.
- Auffälligkeiten dokumentieren. Notieren Sie Fehlermeldung, Uhrzeit, betroffene URL oder Datei und die Region. Das hilft später beim Support – und bei der Einordnung, ob überhaupt ein lokales Problem vorliegt.
- Nur lesend testen. Prüfen Sie, ob Drive und eine Dateiliste in Google Editors wieder laden. Mehr nicht.
- Besteht das Problem nach dem bestätigten Ende weiter und nur auf einem Gerät? Dann prüfen Sie zuerst Internetverbindung und Browser. Google nennt diese Punkte als allgemeine Fehlersuche – sie erklären die bestätigte regionale Cloud-Störung aber nicht rückwirkend.
Das sollten Sie jetzt tun
Bei einer bestätigten Cloud-Störung ist Abwarten fast immer die richtige Strategie. Google hat den Vorfall vollständig serverseitig behoben – durch Migration des regionalen Datenverkehrs auf eine aktualisierte interne Routing-Architektur. Erst nach der Umstellung von 100 % des regionalen Traffics war der Normalbetrieb wiederhergestellt. Ein erster Versuch, den Frontend-Traffic an einen anderen geografischen Standort umzuleiten, blieb wirkungslos und wurde zurückgenommen.
- Nichts an der lokalen Konfiguration ändern. Für diesen Vorfall wurde zunächst kein Workaround veröffentlicht. Es gibt kein App-Update, kein Firmware-Update, keinen lokalen Reparaturschritt.
- Nur bereits vorhandene Offline- oder gespiegelte Dateien nutzen. Der Offlinezugriff ist keine Sofortmaßnahme – Google setzt für dessen Einrichtung unter anderem eine bestehende Internetverbindung voraus.
- Lokale Kopien nicht überschreiben. Wer während der Störung offline weitergearbeitet hat, sollte Dateistände und Versionen sorgfältig abgleichen, bevor eine Synchronisation Konflikte auflöst.
- Geschäftskritische Auswirkungen protokollieren. Google bittet Kunden mit abweichender oder darüber hinausgehender Auswirkung, den Google-Workspace-Support zu kontaktieren.
- Vorsorge treffen. Ein Cloud-Dienst ersetzt kein Backup. Wer seine Sicherungsstrategie prüfen möchte, findet Orientierung im Backup-Assistenten von RESQ.
Das dürfen Sie auf keinen Fall tun
Dieser Abschnitt ist der wichtigste. Denn bei Cloud-Störungen entstehen die echten, dauerhaften Datenverluste fast nie durch den Ausfall selbst – sondern durch das, was Nutzer in Panik dagegen unternehmen.
- Trennen Sie während einer Störung nicht das Google-Konto in Drive for desktop. Google weist ausdrücklich darauf hin, dass dadurch offline gestreamte Dateien vom Gerät entfernt werden. Gespiegelte Dateien bleiben zwar erhalten – aber eine vorhandene lokale Offlinekopie kann so verschwinden, ausgerechnet in dem Moment, in dem sie Ihr einziger Zugang zu den Inhalten ist.
- Löschen Sie keine Drive-Dateien in der Hoffnung, den Fehler „loszuwerden“. Die Störung lag in Googles Infrastruktur. Kein Löschvorgang auf Ihrer Seite behebt eine regionale Netzüberlastung – er entfernt nur Ihre Daten.
- Ändern Sie keine Synchronisations- oder Offline-Einstellungen als „Reparaturversuch“. Google dokumentierte die Behebung als Infrastrukturmigration auf eigener Seite, nicht als Nutzermaßnahme.
- Lösen Sie Synchronisationskonflikte nicht blind auf. Wer beim Konfliktdialog reflexhaft „lokale Version verwerfen“ oder „Cloud-Version überschreiben“ wählt, kann Stunden an Arbeit unwiederbringlich vernichten – und zwar tatsächlich unwiederbringlich, weil hier eine gültige Datei durch eine andere gültige Datei ersetzt wird.
- Formatieren Sie nichts und starten Sie keine Reparatur- oder Prüfprogramme. Für diesen Vorfall gibt es keinerlei Beleg für einen physischen Datenträger- oder Gerätedefekt. Ein Dateisystem-Check, eine „Optimierung“ oder gar eine Neuformatierung eines Laufwerks, auf dem Ihre lokale Kopie liegt, ist reines Risiko ohne jeden Nutzen.
- Installieren Sie keine Wiederherstellungssoftware auf denselben Datenträger, auf dem die vermissten lokalen Daten liegen. Jede Installation schreibt Daten – und überschreibt dabei möglicherweise genau die Bereiche, aus denen sich verlorene Dateien noch rekonstruieren ließen.
Es ist eine unangenehme Wahrheit aus dem Alltag der Datenrettung: Die häufigste Ursache für endgültig verlorene Daten sind nicht Defekte, sondern gut gemeinte Selbstversuche. Ein Ausfall, der nach 12 Stunden und 42 Minuten von allein vorbei war, wird zum echten Schaden, wenn in der Zwischenzeit lokale Kopien gelöscht, überschrieben oder Laufwerke „geprüft“ wurden.
Warum ein solcher Fall in Profihände gehört – und wie RESQ konkret hilft
Die regionale Google-Drive-Störung selbst konnte niemand außer Google beheben. Was Sie als Betroffener beeinflussen können, ist alles, was auf Ihrer Seite liegt: die lokalen Kopien, die synchronisierten Ordner, die Notebooks, SSDs, Festplatten und NAS-Systeme, auf denen Ihre Arbeitsstände liegen. Und genau dort entsteht nach Cloud-Ausfällen der reale Datenverlust.
Typische Schadensbilder, die uns nach solchen Vorfällen erreichen: Eine lokale Offlinekopie wurde durch das Trennen des Kontos entfernt. Ein Nutzer hat versucht, die Synchronisation „neu aufzusetzen“, und dabei den lokalen Ordner geleert. Ein Konfliktdialog wurde falsch beantwortet. Oder es kam schlicht zeitlich unglücklich zusammen: Während der Cloud-Zugriff hakte, gab tatsächlich die Festplatte oder SSD im Notebook auf.
Der entscheidende Unterschied zur Selbsthilfe ist die Arbeitsweise. Ein professionelles Datenrettungslabor arbeitet nie am Original. Der betroffene Datenträger wird – soweit technisch möglich – zunächst sektorweise gesichert; alle weiteren Analysen und Rekonstruktionen laufen an dieser Kopie ab. Fehlversuche bleiben damit folgenlos, während jeder Versuch am Original das Bild dauerhaft verändern kann. Bei mechanisch beschädigten Festplatten kommt die Öffnung im Reinraum hinzu, damit keine Partikel auf die Magnetscheiben gelangen; für defekte Elektronik oder Controller stehen Spezialwerkzeug und Ersatzteile bereit. Bei Verbundsystemen ist zusätzlich das Wissen um Reihenfolge, Parität und Metadaten entscheidend – die Datenrettung bei RAID und NAS ist deshalb ein eigenes Fachgebiet, ebenso wie die Datenrettung von Festplatten.
Genauso wichtig ist die Erfahrung mit dem Fehlerbild an sich. Ein 502-Fehler im Browser bedeutet etwas völlig anderes als ein klackerndes Laufwerk oder ein Dateisystem, das nach einem abgebrochenen Sync inkonsistent ist. Eine saubere Diagnose trennt diese Fälle – und verhindert, dass an einem Gerät „repariert“ wird, das überhaupt nicht defekt ist.
Der Ablauf bei RESQ
- Kostenlose Ersteinschätzung. Sie schildern uns den Fall: Was ist passiert, welches Gerät, welcher Zeitpunkt, welche Symptome. Wir ordnen ein, ob überhaupt ein technischer Schaden vorliegt oder ob es sich um eine reine Verfügbarkeitsstörung handelte.
- Analyse im Labor. Wird das Gerät eingesendet, prüfen wir den Zustand des Datenträgers und sichern, wo möglich, zuerst eine Kopie.
- Ehrliche Aussage zu den Aussichten. Wir sagen Ihnen offen, was wir für machbar halten – und was nicht. Datenrettung ist immer eine Einzelfallprüfung; Garantien gibt es in diesem Fach nicht, und wir geben keine.
- Kostenvoranschlag. Sie erhalten eine konkrete Zahl, bevor irgendetwas beauftragt wird.
- Ihre Entscheidung. Erst danach entscheiden Sie, ob wir loslegen sollen.
Den vollständigen Ablauf und unsere Leistungen finden Sie unter Datenrettung bei RESQ. Geht es um einen reinen Gerätedefekt ohne Datenverlust-Fokus – etwa ein Notebook, das nach dem Vorfall nicht mehr startet –, ist die Reparatur bei RESQ der richtige Weg. Wer den Fall direkt prüfen lassen möchte, fordert am schnellsten eine kostenlose Ersteinschätzung und einen Kostenvoranschlag an. Wenn Sie bereits wissen, dass Sie beauftragen wollen, können Sie auch direkt einen Auftrag im Kundenkonto anlegen.
Fazit: Cloud-Ausfall überstanden – aber prüfen Sie Ihre lokalen Daten
Die Google-Drive-Störung vom 18. bis 19. August 2026 ist beendet. Google meldet den Dienst als vollständig wiederhergestellt, andere Workspace-Dienste waren nicht betroffen, und der vorläufige Incident Report vom 20. August nennt keinen Datenverlust. Ein finaler Bericht mit Präventionsmaßnahmen wird nach Abschluss der Untersuchung folgen.
Was bleibt, ist die Erinnerung daran, wie schnell ein reiner Verfügbarkeitsausfall in echten Datenverlust kippen kann – nämlich dann, wenn im Ausnahmezustand an Synchronisation, Offlinekopien oder Datenträgern herumprobiert wird. Wenn Sie nach der Störung Dateien vermissen, wenn eine lokale Kopie verschwunden ist oder ein Laufwerk sich merkwürdig verhält: Schalten Sie das Gerät aus, installieren Sie nichts nach und starten Sie keine Reparaturprogramme.
Lassen Sie den Fall stattdessen prüfen, bevor sich der Zustand verändert. Eine kostenlose Ersteinschätzung kostet Sie nichts außer einer kurzen Beschreibung – und sie ist der einzige Schritt, der Ihre Daten mit Sicherheit nicht schlechter stellt.