# একজন প্রকৌশলী গিটল্যাবের উৎপাদন ডেটাবেস মুছে ফেলেছেন। ৩০০ গিগাবাইট।

Published: 2026-09-10

৩১শে জানুয়ারী, ২০১৭, ২৩:২৭ ইউটিসি: একজন গিটল্যাব প্রকৌশলী, দীর্ঘ রাতের শেষে একটি ভাঙা প্রতিলিপি মেরামত করতে গিয়ে, db2 এর পরিবর্তে db1-এ পোস্টgreSQL ডেটা ডিরেক্টরি মুছে ফেলেন। db1 ছিল প্রধান ডেটাবেস। প্রায় ৩০০ জিবি GitLab.com-এর ডেটাবেস এক বা দুই সেকেন্ডের মধ্যে অদৃশ্য হয়ে যায় এবং পাঁচটি ব্যাকআপ ও প্রতিলিপি পদ্ধতির কোনোটিই কাজ করছিল না। পোস্টমর্টেম: স্প্যামের তীব্রতা থেকে ভুল হোস্টনাম পর্যন্ত সময়রেখা, কেন pg\_basebackup আটকে আছে বলে মনে হয়েছিল, কেন pg\_dump চুপচাপ ব্যর্থ হচ্ছিল (9.6 ডেটাবেসে 9.2 বাইনারি, DMARC দ্বারা ব্যর্থতার ইমেলগুলি বাউন্স করা হয়েছিল), ইউটিউবে সরাসরি সম্প্রচারিত ৬-ঘন্টা পুরানো স্টেজিং স্ন্যাপশট থেকে ১৮-ঘন্টা পুনরুদ্ধার, এবং কে আসলে দায়ী। প্রতিক্রিয়ার রায়: SHIP IT।

Canonical: https://thedailydiff.dev/bn/video/2026-09-10-gitlab-rm-rf/

## এই ভিডিওতে যা আছে

- জানুয়ারী ৩১, ২০১৭: প্রাথমিক ডেটা ডিরেক্টরিতে rm -Rvf; প্রায় ৩০০ জিবি মুছে ফেলা হয়েছে, ৪.৫ জিবি অবশিষ্ট আছে
- ৫টি ব্যাকআপের মধ্যে ৫টিই ব্যর্থ: খালি S3 বাকেট (pg\_dump সংস্করণ অমিল), ডিবিতে কোনো অ্যাজুর স্ন্যাপশট নেই, মুছে ফেলা প্রতিলিপি, ওয়েবহুক ছাড়া দৈনিক LVM কপি
- ফেব্রুয়ারী ১, ১৮:০০ ইউটিসি: একটি ৬-ঘন্টা পুরানো ম্যানুয়াল স্ন্যাপশট থেকে GitLab.com ফিরে এসেছে; লাইভ ডক, লাইভ স্ট্রিম, একটি ফিক্স তালিকা সহ ব্লেমলেস পোস্টমর্টেম

## অনুবাদিত প্রতিলিপি

মূল ইংরেজি বর্ণনা থেকে অনূদিত। উপলব্ধ অডিও এবং ক্যাপশন YouTube দ্বারা নিয়ন্ত্রিত।

0:00 গিটল্যাবের একজন প্রকৌশলী ভুল ডেটাবেস সার্ভারে rm -rf চালান, এবং গিটল্যাব ডট কমের তিনশ গিগাবাইট ডেটা এক বা দুই সেকেন্ডে অদৃশ্য হয়ে যায়, একটি হোস্টনাম পড়তে যে সময় লাগে প্রায় সেই সময়। ২০১৭ সালের ৩১শে জানুয়ারী, রাত ১১:২৭ ইউটিসি। গিটল্যাব টুইট করে যে তারা ভুলবশত প্রোডাকশন ডেটা মুছে ফেলেছে, তাদের ইনসিডেন্ট নোটগুলি ইন্টারনেটের জন্য উন্মুক্ত করে এবং ইউটিউবে পুনরুদ্ধার প্রক্রিয়াটি লাইভ স্ট্রিম করে, প্ল্যাটফর্মে দ্বিতীয় সেরা লাইভ স্ট্রিম। পরের দিন, লিখিতভাবে: পাঁচটি ব্যাকআপ পদ্ধতির মধ্যে,

0:25 কোনোটিই নির্ভরযোগ্যভাবে কাজ করছে না। কীভাবে এটি ঘটে, কেন এটি সম্ভব, এবং আসলে কে দায়ী। এটি The Daily Diff, পোস্টমর্টেম। বিকাল ৫:২০: একজন প্রকৌশলী প্রোডাকশন স্ন্যাপশট করেন স্টেজিং-এ একটি লোড ব্যালেন্সার পরীক্ষা করার জন্য। সন্ধ্যা ৭টা: স্প্যাম ডেটাবেসকে আঘাত করে, সাথে একটি কাজ যা একজন গিটল্যাব কর্মীকে কঠোরভাবে মুছে দেয় ট্রল অপব্যবহারের জন্য রিপোর্ট করেছিল। রাত ১১টা: প্রতিলিপি এত পিছিয়ে পড়ে যে প্রাইমারি ইতিমধ্যেই ডিসকার্ড করে দিয়েছে

0:48 যে লগ এটির প্রয়োজন; একমাত্র সমাধান হল প্রতিলিপি মুছে ফেলা এবং প্রাইমারি আবার অনুলিপি করা আবার। pg\_basebackup কোনো আউটপুট ছাড়াই আটকে থাকে। এটি আসলে চুপচাপ প্রাইমারির জন্য অপেক্ষা করছে; কেউ তা জানে না, এবং রানবুকে তা বলা নেই। প্রকৌশলী, যিনি এগারোটায় কাজ শেষ করতে চেয়েছিলেন, সিদ্ধান্ত নেন যে খালি ডেটা ডিরেক্টরি সমস্যা এবং সেটি সরিয়ে দেন। db1-এ। প্রাইমারিতে। তিনি এক বা দুই সেকেন্ড পরে লক্ষ্য করেন; প্রায় তিনশ গিগাবাইটের মধ্যে,

1:11 ৪.৫ বাকি আছে। ব্যাকআপগুলো। এক: প্রতিদিন S3-তে pg\_dump। বালতি খালি। ক্রন জব একটি অ্যাপ সার্ভারে চলে যেখানে কোনো ডেটাবেস নেই, তাই প্যাকেজটি বেছে নেয় একটি ৯.৬ ডেটাবেসের জন্য পোস্টgreSQL ৯.২ বাইনারি, ব্যর্থ হয়, এবং ইমেল করে ব্যর্থতা, যা DMARC অনুপস্থিতির কারণে বাউন্স করে। দুই: অ্যাজুর ডিস্ক স্ন্যাপশট, ফাইল সার্ভারগুলির জন্য সক্ষম করা হয়েছে, ডেটাবেসগুলির জন্য নয়।

1:32 তিন: প্রতিলিপি, এক ঘন্টা আগে ইচ্ছাকৃতভাবে মুছে ফেলা হয়েছে। চার: দৈনিক স্ন্যাপশট, ২৪ ঘন্টা পুরানো, স্টেজিং সিঙ্ক দ্বারা সমস্ত ওয়েবহুক সরিয়ে ফেলা হয়েছে। পাঁচ: বিকাল ৫:২০ এর ম্যানুয়াল স্ন্যাপশট, একটি সম্পর্কহীন পরীক্ষার জন্য। সেটিই জেতে। পুনরুদ্ধারের অর্থ হল স্টেজিং ডিস্কটি অ্যাজুরের সস্তা স্টোরেজ ব্যবহার করে প্রতি সেকেন্ডে ষাট মেগাবিট গতিতে প্রোডাকশনে ফিরিয়ে আনা: আঠারো ঘন্টা। GitLab ডট কম ১লা ফেব্রুয়ারী সন্ধ্যা ছয়টায় ফিরে আসে ইউটিসি, ছয় ঘন্টার ডেটা পুরনো। গিট ব্লেম: দুটি হোস্টনামের মধ্যে এক অক্ষরের পার্থক্য, এবং পাঁচটি ব্যাকআপ সিস্টেম যা কেউ

1:58 কখনও পুনরুদ্ধার করেনি। প্রকৌশলী নয়। সিইও দ্বারা স্বাক্ষরিত পোস্টমর্টেম, তাকে বেনামী রাখে, প্রোডাকশন প্রম্পটকে লাল রঙ করে, এবং ডেটা স্থায়িত্বের একটি মালিক দেয়, কারণ এতদিন এর কোনো মালিক ছিল না। ধ্বংসের মাত্রা: আঠারো ঘন্টা ডাউন, ছয় ঘন্টার ডেটা হারানো, প্রায় পাঁচ হাজার প্রকল্প, পাঁচ হাজার মন্তব্য, সাতশ নতুন ব্যবহারকারী, এবং পাঁচ হাজার মানুষ একটি অগ্রগতি বার দেখছে।

2:18 হ্যাকার নিউজ লাইভ ডককে ১,১৬২ পয়েন্ট দেয় এবং একটি লাইন তাদের ফিরিয়ে দেয়: পাঁচটি ব্যাকআপের মধ্যে, একটিও না। রায়, পোস্টমর্টেম: প্রতিক্রিয়ার উপর SHIP IT। তারা জনসমক্ষে ঘটনাটি পরিচালনা করে, প্রক্রিয়াটিকে দোষারোপ করে, এবং সমস্যা নম্বর সহ ফিক্স তালিকা প্রকাশ করে। সোমবারের কাজ: একটি ব্যাকআপ পুনরুদ্ধার করুন। যদি আপনি এটি কখনও পুনরুদ্ধার না করে থাকেন, তবে আপনার কাছে একটি নেই। আপনি যে ঘটনাটি সম্পর্কে এখনও কথা বলার অনুমতি পাননি, সেটি আমাকে পাঠান, মন্তব্যে, অথবা daily diff ডট dev-এ।

2:42 এবং আজকের জন্য এটাই পার্থক্য। আমি Axrisi থেকে নিকো। দায়িত্ব সহকারে মার্জ করুন। আমি Axrisi থেকে নিকো। দায়িত্ব সহকারে মার্জ করুন।

## উৎস

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com