Konten disusun AI — bisa keliru. Baca disclaimer lengkap
OVHcloud — Kebakaran Strasbourg 2021
Ringkasan
Apa yang Terjadi
Pada 10 Maret 2021, kebakaran menghancurkan SBG2 dan merusak sebagian SBG1 di kampus OVHcloud Strasbourg. Pembaruan perusahaan mencatat pemulihan bertahap, bukan satu waktu pulih untuk seluruh pelanggan. Laporan 2022 mengakui sebagian pelanggan kehilangan data permanen. Ini kasus kegagalan ketahanan operasional, bukan kebangkrutan OVHcloud.
Profil. OVHcloud menjual infrastruktur private cloud, public cloud, dan web cloud. Grup berkembang dari hosting pada 1999; KKR dan TowerBrook masuk melalui pendanaan €250 juta pada 2016. Dokumen registrasi 2021 menjadi rujukan profil dan pendanaan historis, bukan valuasi terkini.
Anatomi sebab — analisis. Pemicu fisiknya kebakaran; lapisan strukturalnya adalah ketahanan fasilitas dan cakupan pemulihan data. Pada lapisan tata kelola, pelajaran yang ditarik adalah perlunya pemilik risiko lintas fasilitas, produk, dan pemulihan pelanggan. Ini inferensi pembelajaran, bukan bukti bahwa investor memerintahkan penghematan keselamatan. BEA-RI tidak menetapkan penyebab presisi awal api dalam laporan 2022 dan bukan pengadilan penentu tanggung jawab. Faktor eksternal seperti akses aman ke lokasi membatasi kecepatan recovery; desain perlindungan dan pengujian recovery tetap dapat dikelola.
Dampak dan batas cakupan. Netcraft mengukur sekitar 3,6 juta situs pada 464.000 domain tidak dapat diakses; situs, domain, pelanggan, dan data hilang adalah ukuran berbeda. Pada 31 Agustus 2025, laporan perusahaan masih mencatat provisi €12,6 juta terkait konsekuensi insiden. Status ongoing merujuk konsekuensi dan sengketa yang belum seluruhnya dinyatakan selesai dalam bukti terakhir tersebut, bukan kebakaran yang masih berlangsung. Riset 26 September 2026 tidak menetapkan hasil setiap perkara.
Disusun AI dan dapat keliru; bahan pembelajaran, bukan nasihat hukum atau finansial. Verifikasi klaim melalui sumber.
Kronologi
Urutan Kejadian
Kebakaran dan penghentian layanan Strasbourg
SBG2 hancur; sebagian SBG1 rusak. Pemadaman listrik kampus turut menghentikan layanan di bangunan lainnya.
SBG3 mulai beroperasi kembali
Menurut catatan perusahaan, SBG3 kembali operasional pada tanggal ini; pemulihan layanan berlangsung bertahap.
Pemulihan belum identik dengan pengembalian seluruh data
Perusahaan melaporkan Bare Metal, VPS, dan Public Cloud SBG3/SBG4 kembali tersedia, sementara pekerjaan SBG1 dan solusi pengganti berlanjut.
Dampak pada tahun fiskal 2021
Dokumen FY2021 mencatat dampak penurunan pendapatan €28,1 juta serta sekitar €21 juta belanja modal server pengganti. Tanggal adalah akhir periode laporan, bukan tanggal publikasi.
Laporan investigasi keselamatan bertanggal 24 Mei 2022
BEA-RI menerbitkan temuan keselamatan; sebab presisi awal api belum ditetapkan dalam laporan. Tanggal mengikuti tanggal dokumen.
Provisi konsekuensi insiden masih tercatat
Provisi €12,6 juta mencakup biaya ahli, hukum, dan klaim tanggung jawab. Ini estimasi akuntansi, bukan total ganti rugi yang diputus. Tanggal adalah posisi akhir tahun fiskal.
Aktor & Insentif
Siapa yang Terlibat
Manajemen dan tim operasi OVHcloud
Peran dalam Kasus
Menangani pemulihan dan penyediaan kapasitas pengganti. Catatan operasi.
Insentif
Analisis insentif: memulihkan layanan sambil menjaga keselamatan dan kepercayaan pelanggan.
Pelanggan, pengelola aplikasi, dan mitra SaaS
Peran dalam Kasus
Dampak berbeda menurut layanan dan perlindungan datanya. Pengungkapan risiko. Jangan menganggap semua pelanggan memiliki kontrak cadangan yang sama.
Insentif
Analisis insentif: menjaga layanan pengguna akhir serta biaya pemulihan yang terjangkau.
BEA-RI dan layanan penyelamatan
Peran dalam Kasus
Investigasi keselamatan tidak menentukan tanggung jawab hukum. Laporan investigasi.
Insentif
Keselamatan manusia dan pencegahan kejadian berulang.
Pemberi modal dan pengambil keputusan anggaran
Peran dalam Kasus
Pendanaan historis tercatat dalam profil grup; tidak ditemukan bukti yang mengaitkan investor tertentu dengan keputusan perlindungan kebakaran.
Insentif
Inferensi umum: menyeimbangkan investasi kapasitas, harga, dan risiko kerugian operasional.
Insight untuk Founder
Pelajaran dari Kasus Ini
Manajemen risiko — petakan batas kegagalan
Apa yang Terjadi
Satu insiden menghentikan operasi seluruh kampus. FY2021.
Polanya
Inferensi: nama fasilitas berbeda belum menjamin independensi risiko.
Tanda Bahaya Dini
- Label redundansi tanpa peta lokasi fisik.
- Skenario uji hanya kehilangan satu mesin.
Aksi Pencegahan
- COO dan CTO memetakan listrik, jaringan, akses fisik, dan lokasi cadangan per layanan.
- Uji kehilangan satu kampus sebelum menjual janji kontinuitas. Biaya lokasi kedua harus masuk harga layanan.
Produk — nyatakan cakupan cadangan
Apa yang Terjadi
Pengungkapan 2022 menyebut backup berbayar bersifat opsional bagi kebanyakan pelanggan. Sumber.
Polanya
Inferensi: pembeli dapat menyamakan penyewaan komputasi dengan jaminan pemulihan data.
Tanda Bahaya Dini
- Kontrak hanya menyebut uptime.
- Tidak ada pemilik keputusan retensi dan target kehilangan data.
Aksi Pencegahan
- Tampilkan lokasi, retensi, serta batas kehilangan data yang disepakati sebelum pembelian.
- Minta persetujuan eksplisit atas layanan tanpa backup; jangan menyamarkannya sebagai perlindungan penuh.
Tata kelola — keselamatan lintas fungsi
Apa yang Terjadi
BEA-RI merekomendasikan audit kerentanan fasilitas. Sumber.
Polanya
Inferensi: risiko fisik perlu masuk tinjauan produk, bukan berhenti pada pengelola gedung.
Tanda Bahaya Dini
- Pemilik risiko fasilitas tidak hadir dalam persetujuan SLA.
- Temuan audit tidak memiliki tenggat dan anggaran.
Aksi Pencegahan
- Tunjuk penanggung jawab yang dapat menunda kapasitas baru sampai temuan kritis ditutup.
- Laporkan status mitigasi kepada manajemen, dengan bukti pengujian, bukan hanya pengeluaran anggaran.
Pendanaan — anggarkan biaya recovery
Apa yang Terjadi
FY2021 mencatat belanja modal server pengganti sekitar €21 juta. Sumber.
Polanya
Inferensi: asuransi dan kas pemulihan memenuhi kebutuhan berbeda dari penyelamatan data.
Tanda Bahaya Dini
- Model kas hanya memasukkan penggantian aset.
- Tidak ada anggaran tenaga recovery atau kredit pelanggan.
Aksi Pencegahan
- CFO membuat skenario kas untuk pemulihan, dukungan, kompensasi, dan kapasitas sementara.
- Pisahkan biaya ketersediaan layanan dari nilai data yang tidak dapat dibuat kembali.
Transparansi — laporkan hasil per pelanggan
Apa yang Terjadi
Posting pelanggan mempertanyakan mekanisme penggantian VPS dan kredit. Kesaksian pengguna.
Polanya
Inferensi: status armada pulih belum menjawab apakah aplikasi tertentu dapat dipakai.
Tanda Bahaya Dini
- Pelanggan masih bertanya apakah harus menunggu atau memesan ulang.
- Status hanya menunjukkan persentase agregat.
Aksi Pencegahan
- Berikan status komputasi, data, dan tindakan berikutnya per layanan.
- Ukur waktu sampai pelanggan berhasil melakukan transaksi uji; jangan berhenti pada server yang menyala.
Kultur — dukungan tidak meniadakan evaluasi
Apa yang Terjadi
Sebagian mitra SaaS menyatakan dukungan, sementara pelanggan lain mengkritik. Pemetaan suara.
Polanya
Inferensi: simpati kepada tim bisa berjalan bersama tuntutan perbaikan sistem.
Tanda Bahaya Dini
- Keberhasilan beberapa pelanggan dianggap mewakili semuanya.
- Keluhan dibingkai hanya sebagai kesalahan pengguna.
Aksi Pencegahan
- Tinjau contoh recovery berhasil dan gagal dengan kriteria yang sama.
- Pisahkan kewajiban kontraktual dari bantuan pemulihan darurat; tetapkan pemilik tindak lanjut tanpa menyalahkan engineer.
Bedah Teknikal
Kacamata CTO
Fokus teknisnya fasilitas, batas kegagalan, dan pemulihan data. Layanan yang terdampak mencakup komputasi serta penyimpanan; implementasi aplikasi pelanggan berbeda-beda. Analisis ini tidak menebak stack internal atau konfigurasi setiap pelanggan.
Akar Masalah Teknis
Mitigasi fisik berlapis
Apa yang terjadi
BEA-RI mencatat ruang energi memiliki deteksi, tanpa pemadaman otomatis.
Polanya
Analisis: alarm dan intervensi manual memiliki jeda yang harus dibandingkan dengan laju penyebaran bahaya.
Tanda bahaya dini
- Audit hanya memeriksa alarm berfungsi.
- Tidak ada latihan pengamanan listrik bersama penyelamat.
Pencegahan
- Audit proteksi kebakaran bersama tenaga berwenang.
- Uji prosedur isolasi energi dan akses petugas.
- Verifikasi penutupan temuan sebelum fasilitas diterima.
Independensi lokasi, bukan sekadar jumlah replika
Apa yang terjadi
Inferensi dari penghentian kampus: replika dalam batas bahaya yang sama tidak cukup untuk pemulihan lokasi.
Polanya
Replikasi melindungi dari jenis kegagalan tertentu; cakupannya harus dibuktikan terhadap kejadian berkorelasi.
Tanda bahaya dini
- Cadangan dan produksi berbagi lokasi tanpa pengecualian risiko tertulis.
- Kredensial recovery hanya tersimpan di sistem utama.
Pencegahan
- Inventaris lokasi komputasi, data, kunci, DNS, dan jalur akses recovery.
- Tempatkan salinan yang dapat dipulihkan di lokasi independen.
- Uji pemulihan dengan seluruh lokasi utama dianggap tidak dapat diakses.
Pemulihan data tidak mengikuti penggantian server secara otomatis
Apa yang terjadi
OVHcloud mengungkap kehilangan data permanen bagi sebagian pelanggan tanpa cadangan sendiri.
Polanya
Analisis: provisioning, restore, dan verifikasi aplikasi merupakan gerbang keberhasilan yang berbeda.
Tanda bahaya dini
- Snapshot tersedia tetapi belum pernah dipulihkan.
- Tidak ada inventaris data yang tidak dapat direkonstruksi.
Pencegahan
- Tentukan RPO (batas kehilangan data) dan RTO (target waktu pemulihan) per kelas layanan.
- Pulihkan sampel aplikasi di lingkungan terpisah, lalu verifikasi konsistensi data dan transaksi uji.
- Ukur durasi nyata dan kesenjangan terhadap target.
Risiko sisa melampaui masa downtime
Apa yang terjadi
Provisi konsekuensi insiden masih tercatat pada akhir FY2025.
Polanya
Inferensi: penutupan tiket operasional tidak menutup biaya pemulihan dan sengketa bisnis.
Tanda bahaya dini
- Postmortem ditutup saat infrastruktur menyala.
- Tindak lanjut tanpa anggaran atau bukti hasil.
Pencegahan
- Gabungkan tinjauan engineering, keuangan, dan dukungan setelah recovery.
- Pantau tindakan perbaikan sampai uji ulang lulus.
- Jangan memakai kompensasi finansial sebagai pengganti verifikasi data.
Keputusan Teknis & Trade-off
Cadangan sebagai pilihan layanan
Konteks
Laporan 2022 menjelaskan bahwa backup kebanyakan pelanggan merupakan layanan opsional berbayar.
Trade-off
Analisis: fleksibilitas biaya membutuhkan penjelasan tegas tentang tanggung jawab dan target pemulihan.
Hasil
Perusahaan mengakui kehilangan data permanen pada sebagian pelanggan tanpa cadangan sendiri.
Menguji keselamatan pada tingkat fasilitas
Konteks
Deteksi api saja tidak sama dengan kemampuan memadamkan dan mengisolasi bahaya.
Trade-off
Analisis: perlindungan fisik memerlukan modal serta pengujian, tetapi harus dinilai bersama biaya gangguan layanan.
Hasil
BEA-RI mencatat ketiadaan pemadaman otomatis di ruang energi.
Menyediakan kapasitas pengganti secara bertahap
Konteks
Perusahaan melaporkan relokasi dan penggantian infrastruktur setelah insiden.
Trade-off
Analisis: kapasitas tersedia lebih cepat tidak otomatis membawa kembali isi disk yang musnah.
Hasil
Keberhasilan harus diukur dengan aplikasi dan data pelanggan, bukan jumlah mesin yang disediakan.
Insight untuk CTO
Rekomendasi: buat matriks dependensi pemulihan sebelum memilih bentuk redundansi.
🚩 Peringatan dini
- Dua lokasi logis memakai akses, energi, atau cadangan yang sama.
- Pemulihan membutuhkan sistem identitas yang ikut hilang.
🛡️ Pencegahan
- Simulasikan kehilangan kampus, bukan hanya reboot mesin.
- Buktikan akses ke salinan data dan kunci dari lingkungan yang terpisah.
- Catat dependensi yang belum independen sebagai risiko yang diterima secara eksplisit.
Rekomendasi: perlakukan restore sebagai fitur yang diuji sepanjang umur produk.
🚩 Peringatan dini
- Laporan backup sukses menjadi satu-satunya indikator.
- Tidak ada bukti aplikasi berhasil berjalan dari cadangan.
🛡️ Pencegahan
- Buat uji berkala dengan data representatif.
- Pisahkan waktu penyediaan mesin, pemulihan data, dan validasi bisnis.
- Selidiki setiap kegagalan uji sebelum menambah janji SLA.
Rekomendasi: beli cakupan pemulihan yang dapat dibuktikan, bukan hanya label cloud.
🚩 Peringatan dini
- Lokasi backup dan tanggung jawab pelanggan tidak jelas.
- Tidak diketahui cara mengekspor data jika akun atau lokasi tidak tersedia.
🛡️ Pencegahan
- Lampirkan matriks tanggung jawab pada kontrak.
- Uji akses ekspor serta restore ke lokasi alternatif.
- Timbang biaya dan kompleksitas multi-provider; jangan menganggapnya wajib bila lokasi independen dalam satu provider sudah memenuhi kebutuhan.
Rekomendasi: satukan kepemilikan risiko fisik dan SLO layanan.
🚩 Peringatan dini
- Tim aplikasi menjanjikan waktu pulih tanpa masukan fasilitas.
- Temuan keselamatan tidak terhubung dengan keputusan kapasitas.
🛡️ Pencegahan
- Tunjuk pemilik risiko lintas fasilitas, produk, dan operasi.
- Terapkan gerbang penerimaan dengan bukti uji pemulihan serta persetujuan ahli keselamatan.
- Sediakan kanal pelaporan temuan tanpa menyalahkan individu.
Verdict CTO
Keputusan berikut adalah rekomendasi kontrafaktual, bukan klaim tentang kebijakan internal OVHcloud.
- Sebelum memperluas kapasitas, audit proteksi fisik dengan tenaga berwenang dan pastikan temuan kritis selesai; keandalan aplikasi bergantung pada fasilitas.
- Buat salinan data yang tetap dapat diakses ketika seluruh lokasi utama hilang; uji juga identitas, kunci, dan aksesnya.
- Ubah target recovery menjadi hasil uji aplikasi dengan RPO/RTO per layanan; penyediaan mesin hanyalah satu tahap.
- Biayai latihan kehilangan lokasi dan pemulihan pelanggan dalam rencana tahunan; terima biaya tambahan secara sadar sesuai dampak bisnis.
- Publikasikan status terpisah untuk komputasi, data, dan tindakan pelanggan; jangan menyamakan persentase server pulih dengan data terselamatkan.
Analisis AI untuk pembelajaran; bukan audit fasilitas. Penyebab awal api dan tanggung jawab hukum tidak disimpulkan dari temuan keselamatan.
Sumber
- Strasbourg datacentre: latest information — pembaruan 10 Maret–23 April 2021 — OVHcloud (tier 1)
- Rapport MTE-BEARI-2022-005 — incendie OVH Strasbourg — BEA-RI (tier 1)
- Universal Registration Document 2021 — sejarah dan §7.3.2 Strasbourg fire — OVHcloud (tier 1)
- Universal Registration Document 2022 — risiko insiden Strasbourg, hlm. 42 — OVHcloud (tier 1)
- Universal Registration Document 2025 — provisi insiden Strasbourg, hlm. 268 — OVHcloud (tier 1)
- 3.6 million websites taken offline after fire at OVH datacenters — Netcraft (tier 1)
Sentimen Publik
Bagaimana Publik Memandang
Sentimen mengukur persepsi publik, bukan fakta hukum. Baca metodologi untuk batasan dan bias yang diakui.
Framing ChannelNews menyoroti kontroversi dan kritik; dugaan kelalaian di artikel tidak diadopsi sebagai fakta teknis.
Philippe Pinault dan Alain Garnier menyatakan dukungan; pemilihan ini mencerminkan suara pendukung dalam liputan, bukan seluruh founder.
Rui_PauloD dan MassimilianoB mengeluhkan konsekuensi biaya dan penggantian VPS. Pernyataan mereka tidak diverifikasi terhadap akun atau kontrak.
BEA-RI berfokus pada pencegahan dan audit; tidak menentukan tanggung jawab hukum.