Şimdi arkadaşlar, üretim ortamında yaşanan bir veri kaybı ve sonrasında o veriyi nasıl kurtardığımızdan bahsedeceğim. Hani bazen her şey tıkırında gidiyor ya, tam da böyle bir anda başımıza geldi bu olay. Her şey normal akışında devam ederken, bir baktık ki… yok olmuş bazı şeyler.
Böyle bir şey olunca ilk tepki ne oluyor tabii? Panik! Hele ki Production ortamında, hele ki önemli bir veri… Ama sakin kalmak lazım, hemen paniğe kapılmak yerine durumu anlamaya çalışmak gerekiyor. İlk başta neden böyle bir şey olduğunu anlamak için biraz inceleme yaptık.
Açıkçası, olayın kaynağını bulmak biraz zaman aldı. Bazen en basit şeyler en büyük sorunlara yol açabiliyor, değil mi? Mesela bir disk doluluğu, bir yetkilendirme sorunu, ya da daha kötüsü, bir yanlış komut… Bizim olayda da tam olarak ne olduğunu anlamak için loglara daldık, sistemleri didik didik ettik. Gerçekten bazen o logların içinde kayboluyorsun ama mecbur bakacaksın işte.
Neticede, olayın sebebini biraz olsun aydınlatabildik. Tam olarak ne olduğunu çözdüğümüzde, kurtarma yöntemlerine geçtik. Bu noktada en kritik şey, kurtarma planınızın hazır olması. Yani, “Bir gün başıma gelirse ne yaparım?” sorusunun cevabının cebinizde olması lazım. Bizim de şükür ki bir yedeğimiz vardı, ama bu yedekten de veriyi nasıl çekeceğimizi planlamamız gerekiyordu.
Bu arada, Production’daki veri kaybını engellemek için alabileceğiniz önlemler var tabii. Mesela düzenli yedekleme zaten şart. Ama onun ötesinde, erişim kontrollerini sıkı tutmak, kritik operasyonlar için çift kontrol mekanizmaları kurmak gibi şeyler de hayat kurtarıyor. Hani o kadar uğraşıp bir şeyleri kaybetmeyelim, değil mi?
Kurtarma sürecine gelirsek… Öncelikle yedeklerin sağlamlığını kontrol ettik. Bir yedek var ama bozuksa veya eksikse, o zaman işler daha da sarpa sarar. Bizim yedekler sağlamdı, bu büyük bir şanstı galiba. Sonra, yedekten sadece kaybolan veriyi nasıl çekeceğimizi belirledik. Tüm veritabanını geri yüklemek yerine, ihtiyacımız olan kısımları çekmek daha hızlı ve daha az riskli oluyor.
Burada işin içine biraz teknik bilgi giriyor tabi. Hangi komutları kullanacağız, hangi araçları devreye sokacağız… PostgreSQL kullanıyorsanız, ‘pg_restore’ gibi araçlar gerçekten hayat kurtarıcı olabiliyor. Amacımız, mümkün olduğunca az müdahaleyle, en hızlı şekilde veriyi geri getirmekti.
Şimdi, ben bu tür durumlar için basit bir script hazırlamıştım aslında, ama Production’da çalıştırmadan önce hep test ortamında denemek lazım. Hani kendi yazdığınız kod bile bazen sizi şaşırtabiliyor 🙂
İşte bu noktada, kaybolan veriyi çekmek için kullandığımız yöntemlerden biri şöyleydi:
-- YANLIŞ YÖNTEM (TÜM DATABASE'İ RESTORE ETMEK - RİSKLİ!) -- Bu yöntem, tüm veritabanını geri yükler ve mevcut veriyi üzerine yazar. -- Production'da önerilmez!-- pg_restore -h localhost -p 5432 -U postgres -d your_database_name --clean --create backup.dump
-- DOĞRU YÖNTEM (Sadece İhtiyaç Duyulan Tabloları Restore Etme - Daha Güvenli!) -- Bu yöntem, spesifik tabloları veya şemaları hedefleyerek kurtarma yapar. -- Öncelikle, kurtarmak istediğiniz tabloları belirleyin. -- Sonra, bu komutla sadece o tabloları çekin.
-- Örnek: Sadece 'users' tablosunu kurtarma -- Önce bir geçici veritabanı oluşturup oraya restore edebilirsiniz. -- Sonra 'users' tablosunu ana veritabanınıza taşırsınız.
-- 1. Geçici veritabanı oluşturma (opsiyonel ama önerilir) -- CREATE DATABASE temp_recovery;
-- 2. Yedekten sadece 'users' tablosunu geçici veritabanına çekme -- pg_restore -h localhost -p 5432 -U postgres -d temp_recovery -t users backup.dump
-- 3. Ana veritabanınızdaki 'users' tablosunu yedekleyin (güvenlik için!) -- pg_dump -h localhost -p 5432 -U postgres -t users your_database_name > users_backup_before_restore.sql
-- 4. Geçici veritabanındaki 'users' tablosunu ana veritabanına taşıma -- INSERT INTO your_database_name.users SELECT * FROM temp_recovery.users;
-- 5. Geçici veritabanını silme -- DROP DATABASE temp_recovery;
-- Not: Bu örnekler PostgreSQL içindir. Farklı veritabanları için komutlar değişir. -- Detaylar için: https://www.postgresql.org/docs/current/app-pgrestore.html
İşte böyle, adım adım ilerledik. Bazen en karmaşık görünen sorunların çözümü bile aslında basit mantıklara dayanıyor, hani sadece doğru adımları takip etmek gerekiyor. Bu arada, bu tür bir veri kaybını yaşamamak için düzenli yedekleme ve felaket kurtarma planları çok önemli. Hani ne olur ne olmaz, değil mi?
Sonuç olarak, Production’da yaşadığımız bu veri kaybı olayı bize hem ders oldu hem de elimizdeki yedekleme ve kurtarma mekanizmalarının ne kadar değerli olduğunu bir kez daha gösterdi. İnanın ki bu tür durumlar yaşandığında, sakin kalıp doğru adımları izlemek en önemlisi. Ve tabii, her zaman bir B planınızın olması şart.
Bu arada, benzer bir durum yaşayan varsa veya farklı kurtarma yöntemleri bilen varsa, yorumlarda paylaşabilir. Bilgi paylaştıkça çoğalır sonuçta. Belki benim kullandığım yöntem herkes için uygun olmayabilir, başka daha iyi çözümler de vardır kim bilir.
Unutmayın, teknoloji ilerledikçe riskler de değişiyor ama önlemler de artıyor. Önemli olan bu akışa ayak uydurabilmek. Hadi bakalım, hepinize kazasız belasız kodlamalar 🙂