İşlem Günlükleri (Transaction Logs) ve Veri Kurtarma

Veritabanında yanlışlıkla milyonlarca kaydı güncellediğinizi ve hatayı beş dakika sonra fark ettiğinizi düşünün. Elinizde yalnızca gece alınmış bir full backup varsa birkaç dakikalık hatayı düzeltmek için saatlerce üretilmiş doğru veriyi de kaybetme riskiyle karşılaşırsınız. İşlem Günlükleri (Transaction Logs) ve Veri Kurtarma tam olarak bu noktada önem kazanır. Transaction log ile veri kurtarma nasıl yapılır sorusunun cevabı, database teknolojisinin log modelini, kesintisiz log zincirini, base backup yapısını ve doğru recovery target seçimini birlikte anlamaktan geçer. On yıllık veritabanı ve yazılım projelerindeki deneyimimde en kritik derslerden biri, başarılı görünen bir backup işinin gerçek bir kurtarma garantisi vermediğini görmek oldu. Bu rehberde veritabanı işlem günlükleri nasıl yedeklenir ve geri yüklenir, SQL Server PostgreSQL ve MySQL transaction log kurtarma yöntemleri nasıl farklılaşır ve transaction log backup point in time recovery ve felaket kurtarma stratejileri nasıl birlikte tasarlanır sorularını uygulama odaklı biçimde ele alacağız.

İşlem Günlüğü (Transaction Log) Nedir?

Transaction log, veritabanında gerçekleşen değişikliklerin belirli bir sırayla kaydedildiği dahili kayıt mekanizmasıdır. Temel görevi uygulama kullanıcılarına okunabilir olay geçmişi sunmak değil, database engine'in transaction bütünlüğünü, crash recovery sürecini ve bazı sistemlerde point-in-time recovery yeteneğini desteklemektir. Bir satırın güncellenmesi sırasında veri sayfasının hemen kalıcı diske yazılması şart değildir, fakat değişikliğin güvenli biçimde loglanması durability açısından kritik olabilir. Log yapısı database teknolojisine göre WAL, redo log, transaction log veya binary log gibi farklı isimler ve görev ayrımları kullanabilir. Bu nedenle transaction log kavramını tek bir dosya formatı gibi düşünmek yerine database engine'in değişiklikleri güvenli biçimde takip ettiği mekanizmalar bütünü olarak görmek daha doğru olur.

Transaction Log Ne İşe Yarar?

Transaction log'un ilk önemli görevi tamamlanmış işlemlerin sistem çökmesi sonrasında kaybolmasını önlemeye yardımcı olmaktır. Database server beklenmedik biçimde kapanırsa engine log kayıtlarından yararlanarak hangi değişikliklerin tamamlandığını ve hangilerinin yarım kaldığını belirleyebilir. İkinci önemli kullanım alanı backup ve recovery süreçleridir, çünkü uygun log arşivi bulunan sistemlerde database belirli bir zamana kadar ileri taşınabilir. Ayrıca replication, CDC ve log shipping gibi mekanizmalar da transaction değişikliklerini takip etmek için log altyapısından yararlanabilir. Logların işletilmesi bu nedenle yalnızca DBA ekibinin disk yönetimi işi değildir, doğrudan RPO, RTO ve veri bütünlüğü hedeflerini etkileyen mimari bir konudur.

Hangi Database İşlemleri Günlüğe Yazılır?

Hangi işlemin hangi ayrıntıyla loglandığı database engine'e ve kullanılan log türüne göre değişir. Genel olarak kalıcı veri durumunu değiştiren INSERT, UPDATE ve DELETE işlemlerinin recovery için gerekli bilgilerinin log yapısında yer alması beklenir. Schema değiştiren bazı DDL işlemleri de transaction ve recovery mekanizmasına dahil olabilir. COMMIT ve ROLLBACK gibi transaction sınırları database engine'in hangi değişikliğin kalıcı sayılacağını anlaması açısından önemlidir. Uygulama geliştiricisinin burada dikkat etmesi gereken nokta, logun sıradan SQL geçmişi olmadığı ve fiziksel ya da mantıksal recovery ihtiyaçlarına göre database tarafından özel formatta tutulduğudur.

INSERT

INSERT işlemi yeni bir kaydın veritabanına eklenmesini sağlar ve değişikliğin recovery sırasında yeniden oluşturulabilmesi için ilgili bilgi log mekanizmasında temsil edilir. Database engine kullanılan storage yapısına göre yalnızca SQL metnini değil, page veya row değişikliklerini ifade eden daha düşük seviyeli bilgiler de kaydedebilir. Commit tamamlanmadan önce oluşan kayıtların crash sonrasında kalıcı kabul edilip edilmeyeceği transaction durumuna bağlıdır. Bu nedenle log içindeki bir değişikliği görmek tek başına o işlemin kullanıcı açısından başarıyla tamamlandığını göstermez. Recovery motoru commit durumu, sequence bilgisi ve diğer log kayıtlarını birlikte değerlendirerek doğru sonuca ulaşır.

UPDATE

UPDATE mevcut kaydın belirli alanlarını değiştirir ve bu değişiklik recovery için gerekli ölçüde loglanır. Bazı sistemler değişikliğin önceki durumunu, bazıları yeni page değişikliğini veya her ikisini farklı log mekanizmalarında yönetebilir. Büyük toplu güncellemeler kısa sürede çok yüksek log hacmi üretebilir ve disk büyümesine neden olabilir. Bu yüzden migration veya batch işlemleri öncesinde yalnızca data file kapasitesi değil transaction log alanı da hesaplanmalıdır. Yanlış UPDATE senaryosu aynı zamanda PITR kullanımının en güçlü örneklerinden biridir, çünkü doğru log zinciri sayesinde database hatalı transaction'dan hemen önceki noktaya getirilebilir.

DELETE

DELETE işlemi kullanıcı açısından kaydı ortadan kaldırır ancak database engine recovery, MVCC veya undo mekanizması nedeniyle ilgili bilgileri bir süre farklı yapılarda tutabilir. Hatalı bir DELETE commit edildikten sonra normal ROLLBACK çoğu zaman mümkün değildir, çünkü transaction artık tamamlanmıştır. Bu durumda backup ve log tabanlı point-in-time recovery, kaybolan veriyi ayrı recovery instance üzerinde yeniden elde etmek için kullanılabilir. Production database'i doğrudan eski zamana döndürmek yerine yalnızca silinen kayıtları kurtarmak çoğu olayda daha düşük risklidir. Özellikle yüksek trafikli sistemlerde yanlış DELETE'ten sonra gerçekleşen doğru işlemleri korumak için selective recovery yaklaşımı dikkatle değerlendirilmelidir.

DDL İşlemleri

DDL işlemleri tablo, indeks veya schema yapısını değiştiren komutları kapsar. Bir DROP TABLE, ALTER TABLE veya benzeri işlem uygulama verisini doğrudan değiştirmese bile database yapısı üzerinde çok büyük etki oluşturabilir. Database teknolojisinin transactional DDL desteğine göre bu değişikliklerin rollback ve recovery davranışı farklılaşabilir. Deployment pipeline içinde migration kimliği ile database recovery marker bilgisini eşleştirmek bu nedenle değerli bir pratiktir. Hatalı schema migration sonrasında yalnızca uygulama sürümünü geri almak yeterli olmayabilir, çünkü database state'i ayrıca uygun backup ve transaction log noktası kullanılarak doğrulanmalıdır.

COMMIT ve ROLLBACK

COMMIT transaction içindeki değişikliklerin kalıcı kabul edildiği sınırı temsil eder. Database engine durability garantisini sağlamak için commit yanıtından önce gerekli log kayıtlarının güvenli biçimde kalıcı ortama yazılmasını bekleyebilir. ROLLBACK ise tamamlanmamış transaction içindeki değişikliklerin kullanıcı açısından geçersiz sayılmasını sağlar. Crash recovery sırasında da benzer mantıkla tamamlanmış işlemler korunurken tamamlanmamış işlemlerin etkileri geri alınabilir veya görünmez hâle getirilebilir. Bu sınırlar veri kurtarma analizinde önemlidir, çünkü hatalı SQL'in çalıştığı zaman ile transaction'ın gerçekten commit edildiği zaman aynı olmayabilir.

Transaction Log ile Application Log Arasındaki Fark

Application log uygulamanın iş akışı, hata, performans ve kullanıcı işlemleri hakkında geliştirici tarafından üretilen kayıttır. Transaction log ise database engine tarafından veri bütünlüğü ve recovery amacıyla yönetilen dahili mekanizmadır. Application log içinde “sipariş güncellendi” gibi okunabilir mesaj bulunabilirken transaction log storage page veya row değişikliklerini database'e özgü binary formatta tutabilir. Application log'un silinmesi crash recovery mekanizmasını doğrudan bozmaz, fakat database transaction log zincirinin kaybolması PITR kabiliyetini ciddi biçimde etkileyebilir. Incident analizi sırasında iki log türünü birlikte kullanmak faydalıdır, çünkü application log olayın iş bağlamını verirken transaction log gerçek database değişikliğinin recovery koordinatını bulmaya yardımcı olabilir.

Transaction Log ile Audit Log Arasındaki Fark

Audit log temel olarak kim, ne zaman, hangi kaynağa erişti veya hangi yönetim işlemini yaptı sorularına cevap vermeyi amaçlar. Transaction log ise database recovery ve transaction durability ihtiyaçlarına hizmet eder. Bir transaction log kaydında değişikliğin teknik bilgisi bulunması, kullanıcı kimliği ve iş gerekçesinin eksiksiz audit edildiği anlamına gelmez. Benzer biçimde ayrıntılı audit log sahibi olmak da PITR için gereken transaction log arşivinin yerine geçmez. Kurumsal sistemlerde güvenlik, uyumluluk ve recovery gereksinimleri farklı kayıt mekanizmalarıyla karşılanmalı ve bu sistemlerin saklama süreleri kendi amaçlarına göre belirlenmelidir.

Transaction Log, WAL, Redo, Undo ve Binlog Aynı Şey mi?

Bu kavramlar birbirine yakın alanlarda kullanılsa da aynı mekanizmayı ifade etmez. SQL Server transaction log hem crash recovery hem log backup zinciri için merkezi rol oynarken PostgreSQL WAL, write-ahead logging ve continuous archiving modelinin temelidir. MySQL InnoDB redo log crash recovery tarafında görev yaparken binary log replication ve point-in-time recovery açısından ayrı öneme sahiptir. Undo log ise geçmiş row sürümleri ve transaction rollback gibi farklı amaçlara hizmet eder. Oracle tarafında redo, archived redo ve undo mekanizmalarının rolleri de ayrıdır. Bu ayrımları bilmeden hazırlanan recovery runbook, bir database teknolojisindeki yöntemi diğerine yanlış biçimde uygulayabilir.

SQL Server Transaction Log

SQL Server transaction log her database için transaction değişikliklerini sıralı biçimde kaydeden temel recovery yapısıdır. Full ve bulk-logged recovery model kullanımlarında transaction log backup alınarak log zinciri korunabilir ve uygun koşullarda point-in-time restore yapılabilir. SIMPLE recovery modelinde transaction log backup desteği bulunmadığı için PITR stratejisi aynı şekilde kurulamaz. Log içindeki LSN değerleri backup ve restore sırasının doğru kurulmasında kritik rol oynar. Ayrıca log dosyasının büyümesi yalnızca dosyanın büyük olduğu anlamına gelmez, aktif transaction, eksik log backup veya replica gecikmesi gibi bir log truncation engeli bulunduğunu gösterebilir.

PostgreSQL WAL

PostgreSQL WAL, Write-Ahead Log kavramının uygulamasıdır ve değişikliklerin data page'lerden önce loglanmasına dayanır. WAL segmentlerinin uygun şekilde archive edilmesi ve base backup ile birlikte korunması PostgreSQL PITR modelinin temelini oluşturur. Recovery sırasında restore_command aracılığıyla gerekli archived WAL segmentleri sırayla alınabilir ve belirlenen recovery target'a kadar replay edilebilir. PostgreSQL ayrıca LSN, transaction ID, timestamp ve named restore point gibi farklı hedefleme seçenekleri sunar. Promotion sonrasında yeni timeline oluşması nedeniyle PITR runbook yalnızca WAL dosyalarını değil timeline history bilgisini de doğru yönetmelidir.

MySQL InnoDB Redo Log

InnoDB redo log, tamamlanmış veri değişikliklerinin crash sonrasında yeniden uygulanabilmesini destekleyen temel storage engine mekanizmasıdır. Buffer pool içindeki dirty page henüz data file'a yazılmamış olsa bile gerekli redo bilgisi kalıcı ortamda bulunabilir. Bu yapı crash recovery için önemlidir ancak MySQL PITR sürecinde tek başına kullanıcı tarafından archive edilip uygulanan transaction geçmişi olarak düşünülmemelidir. Point-in-time recovery için MySQL binary log daha doğrudan rol oynar. Bu ayrım önemlidir, çünkü redo log ile binary log'un aynı şey olduğunu varsayan bir backup planı gerçek recovery sırasında ihtiyaç duyulan event geçmişini sunmayabilir.

MySQL Undo Log

MySQL InnoDB undo log transaction rollback ve MVCC davranışı için eski row sürümlerinin tutulmasına yardımcı olur. Henüz commit edilmemiş işlemin geri alınabilmesi bu mekanizmanın önemli kullanım alanlarından biridir. Uzun süre açık kalan transaction'lar geçmiş row sürümlerinin daha uzun süre korunmasına ve purge süreçlerinin gecikmesine neden olabilir. Undo log, kullanıcıların haftalar sonra yanlış DELETE işlemini geri almak için kullanacağı genel amaçlı PITR arşivi değildir. Bu nedenle işletme seviyesinde veri kurtarma tasarımı full backup ve binary log gibi kalıcı recovery kaynaklarını ayrıca güvence altına almalıdır.

MySQL Binary Log

MySQL binary log database içeriğini değiştiren event'leri kaydeder ve replication ile point-in-time recovery için kullanılır. Full veya uygun base backup geri yüklendikten sonra backup sonrasında oluşan binlog event'leri mysqlbinlog gibi araçlarla belirli zamana veya position değerine kadar yeniden uygulanabilir. ROW, STATEMENT ve MIXED formatlarının recovery ve replication davranışı açısından farklı özellikleri bulunur. Binlog retention süresi kısa tutulursa olay geç fark edildiğinde gerekli event dosyaları çoktan silinmiş olabilir. Bu nedenle binlog saklama süresi yalnızca disk maliyetine göre değil incident detection, recovery hazırlığı ve RPO hedeflerine göre belirlenmelidir.

Oracle Redo Log

Oracle redo log database üzerinde gerçekleşen değişiklikleri recovery amacıyla kaydeden kritik mekanizmadır. Online redo log dosyaları database çalışırken döngüsel biçimde kullanılabilir ve crash ya da instance recovery süreçlerinde önemli rol oynar. ARCHIVELOG yaklaşımı kullanıldığında dolan redo log içerikleri archived redo olarak korunarak daha geniş media recovery seçenekleri elde edilebilir. Redo bilgisi ile undo bilgisi farklı görevleri yerine getirir ve bu ayrım Oracle recovery mimarisini anlamak açısından önemlidir. Kurumsal recovery planı online redo dosyalarının varlığını backup kabul etmemeli ve arşiv, backup, recovery catalog ile test süreçlerini birlikte değerlendirmelidir.

Oracle Archived Redo Log

Archived redo log, dolan online redo log içeriğinin kalıcı archive kopyasıdır. Bu kayıtlar base backup sonrasında gerçekleşen değişikliklerin recovery sırasında yeniden uygulanmasına yardımcı olur. Yeterli archive retention bulunmazsa hedeflenen recovery zamanına ulaşmak mümkün olmayabilir. Archive destination kapasitesi dolduğunda production işlemlerinin etkilenebileceği senaryolar da planlanmalıdır. Bu nedenle archive başarısızlıkları yalnızca storage alarmı olarak değil potansiyel recoverability kaybı olarak ele alınmalı ve merkezi monitoring sisteminde yüksek öncelikli olay olarak izlenmelidir.

Oracle Undo

Oracle undo, transaction rollback, read consistency ve bazı flashback özellikleri için geçmiş veri durumunun yönetilmesini destekler. Redo ile aynı görevi yapmaz ve uzun süreli recovery arşivi olarak görülmemelidir. Undo retention sorguların tutarlı geçmiş görüntüye erişebilmesini etkileyebilir ancak PITR için gereken redo ve backup zincirinin yerine geçmez. Büyük veya uzun transaction'lar undo tüketimini belirgin biçimde artırabilir. Recovery planında hangi özelliğin kısa süreli mantıksal düzeltme, hangisinin gerçek database restore amacı taşıdığı açıkça ayrılmalıdır.

Teknolojiler Arası Karşılaştırma

SQL Server'da transaction log backup zinciri merkezi öneme sahipken PostgreSQL'de base backup ve WAL archive modeli öne çıkar. MySQL'de InnoDB redo crash recovery sağlar, binary log ise replication ve PITR için daha doğrudan kullanılır. Oracle'da online redo, archived redo ve undo mekanizmaları farklı roller üstlenir. Bu farklılıklar nedeniyle “transaction log backup alıyoruz” ifadesi teknoloji belirtilmeden recovery kabiliyetini açıklamak için yeterli değildir. Sağlıklı kurumsal envanter her database için hangi log türünün crash recovery, PITR, replication ve audit ihtiyaçlarından hangisini karşıladığını açık biçimde kaydetmelidir.

Write-Ahead Logging (WAL) Nasıl Çalışır?

Write-Ahead Logging yaklaşımının temel fikri, değişen data page diske yazılmadan önce o değişikliği yeniden oluşturmak için gerekli log bilgisinin kalıcı biçimde kaydedilmesidir. Bu yöntem database'in her transaction sırasında bütün data page'leri anında diske yazmak zorunda kalmadan yüksek performans ile durability arasında denge kurmasını sağlar. Uygulama commit aldığında ilgili data page hâlâ buffer cache içinde dirty durumda bulunabilir. Sunucu bu noktadan hemen sonra kapanırsa restart sırasında WAL kullanılarak gerekli değişiklikler yeniden uygulanabilir. Böylece database engine storage yazma sırasını kontrol ederek hem performansı artırır hem de crash recovery için güvenilir bir kronolojik kayıt oluşturur.

Buffer Cache

Buffer cache sık kullanılan database page'lerinin bellekte tutulduğu alandır. Query bir row'u güncellediğinde disk üzerindeki page'in hemen değiştirilmesi yerine bellekteki kopya güncellenebilir. Bu yaklaşım her küçük değişiklikte rastgele disk yazımı yapılmasını azaltarak performansı önemli ölçüde iyileştirir. Ancak memory kalıcı olmadığı için database engine değişikliğin güvenli recovery bilgisini log mekanizmasında saklamak zorundadır. Buffer cache davranışını anlamak, commit olmuş bir transaction'ın data page'i henüz disk file üzerinde güncel değilken neden yine de durable sayılabildiğini anlamanın temelidir.

Dirty Page

Dirty page, bellekteki içeriği disk üzerindeki kalıcı kopyadan farklı hâle gelmiş database page'idir. Transaction bir row'u değiştirdiğinde ilgili page dirty olarak işaretlenebilir ve daha sonra background writer veya checkpoint süreci tarafından diske yazılabilir. Commit ile dirty page flush işleminin aynı anda gerçekleşmesi zorunlu değildir. Database log mekanizması gereken değişikliği önceden kalıcı hâle getirdiği için data page daha uygun zamanda yazılabilir. Çok yüksek dirty page miktarı checkpoint ve recovery davranışını etkileyebileceğinden performans izleme sırasında sadece transaction sayısı değil dirty buffer eğilimleri de değerlendirilmelidir.

Log Buffer

Log buffer transaction değişikliklerine ait log kayıtlarının önce memory üzerinde toplandığı alandır. Her log kaydını ayrı fiziksel write ile diske göndermek performans açısından pahalı olacağı için database engine grup hâlinde flush yapabilir. Commit sırasında ilgili transaction'ın durability gereksinimini sağlayacak log kayıtlarının kalıcı ortama ulaştığından emin olunur. Group commit gibi teknikler birden fazla transaction'ın log flush maliyetini paylaşmasına yardımcı olabilir. Log buffer kapasitesi ve flush davranışı özellikle yüksek transaction yoğunluğuna sahip sistemlerde latency ve storage performansının birlikte değerlendirilmesini gerektirir.

Log Flush

Log flush memory içindeki log kayıtlarının kalıcı storage'a yazılması işlemidir. Durability garantisi açısından commit yanıtının hangi noktada verildiği database yapılandırmasına göre önem taşır. Senkron durability kullanılan tipik modelde transaction başarıyla commit edildi denmeden önce gerekli log kayıtlarının kalıcı olduğundan emin olunur. Storage latency yüksekse commit latency de bundan doğrudan etkilenebilir. Bu nedenle log disk tasarımı yalnızca kapasite problemi değildir, transaction response süresi ve recovery güvenliği üzerinde belirleyici etkisi bulunan performans bileşenidir.

Data Page Flush

Data page flush dirty page'in memory'den kalıcı database file'a yazılmasıdır. Bu işlem çoğu sistemde transaction commit anıyla birebir eşleşmek zorunda değildir. Checkpoint veya background writer gibi mekanizmalar page yazımlarını daha düzenli biçimde gerçekleştirebilir. WAL yaklaşımı sayesinde crash meydana gelirse disk üzerinde eski page bulunsa bile log replay ile committed durum yeniden oluşturulabilir. Data page flush hızının storage kapasitesinden geri kalması çok fazla dirty page ve daha ağır checkpoint yükü oluşturabileceği için uzun vadeli performans izleme içinde dikkate alınmalıdır.

Log Kaydı Neden Veriden Önce Diske Yazılır?

Log kaydının önce yazılması crash sonrasında hangi değişikliğin yeniden uygulanması gerektiğinin güvenli kanıtını oluşturur. Data page önce yazılıp gerekli recovery kaydı kaybolursa database tutarlılığını yeniden kurmak zorlaşabilir. WAL prensibi bu nedenle storage write sırasına açık bir güvenlik kuralı getirir. Commit edilmiş transaction'ın data page'i henüz kalıcı file'a yazılmamış olsa bile log mevcutsa database restart sırasında değişikliği yeniden uygulayabilir. Bu yaklaşım performans açısından da faydalıdır, çünkü sıralı log yazımları birçok küçük ve dağınık data page yazımına göre storage tarafından daha verimli işlenebilir.

WAL ve ACID Durability İlişkisi

ACID içindeki Durability, başarıyla commit edilen transaction'ın sistem arızası sonrasında kaybolmaması beklentisini ifade eder. WAL bu hedefe ulaşmak için kullanılan temel tekniklerden biridir. Transaction commit edilmeden önce gerekli log bilgisinin kalıcı ortama ulaşması, data page daha sonra yazılsa bile değişikliğin yeniden oluşturulabilmesini sağlar. Elbette gerçek durability storage hardware, fsync davranışı, database ayarı ve altyapının write acknowledgement güvenilirliğine de bağlıdır. Bu yüzden production performansını artırmak amacıyla durability ile ilgili ayarları gevşetmek yalnızca hız ayarı olarak değil doğrudan veri kaybı riski taşıyan mimari karar olarak değerlendirilmelidir.

Bir Transaction Commit Edildiğinde Ne Olur?

Commit işlemi geliştirici açısından tek bir komut gibi görünse de database engine içinde birden fazla adım gerçekleşir. Transaction başlar, değişiklikler buffer yapılarında uygulanır ve gerekli log kayıtları oluşturulur. Commit talebi geldiğinde durability için gereken log kayıtları kalıcı ortama flush edilir ve transaction'ın tamamlandığını gösteren kayıt oluşturulur. Uygun güvence sağlandıktan sonra client başarı yanıtı alabilir. Data page'lerin tamamının aynı anda disk file'a yazılması gerekmez. Bu ayrım crash recovery davranışını, storage performansını ve neden transaction log disklerinin düşük latency gerektirdiğini anlamak açısından önemlidir.

Transaction Başlangıcı

Transaction başladığında database engine işlemleri tek mantıksal birim altında takip etmeye başlar. Isolation seviyesi ve storage engine davranışına göre transaction farklı lock veya version bilgileriyle ilişkilendirilebilir. Kullanıcı henüz hiçbir değişiklik yapmamış olsa bile transaction'ın yaşam süresi database kaynak kullanımını etkileyebilir. Çok uzun açık kalan transaction'lar log truncation, MVCC cleanup veya lock beklemeleri gibi problemler oluşturabilir. Bu nedenle uygulama kodunda transaction sınırlarını mümkün olduğunca kısa ve açık tutmak yalnızca performans için değil recovery ve log yönetimi açısından da iyi bir pratiktir.

Veri Değişikliklerinin Loglanması

Transaction içindeki INSERT, UPDATE veya DELETE gibi değişiklikler database engine'in recovery mekanizmasına uygun biçimde loglanır. Bu log kayıtları işlemin tamamen commit olduğu anlamına gelmez, çünkü transaction daha sonra rollback olabilir. Engine kayıtları transaction kimliği veya sequence bilgileriyle ilişkilendirerek hangi değişikliğin hangi transaction'a ait olduğunu takip eder. Büyük transaction'lar commit öncesinde bile çok fazla log alanı tüketebilir. Bu yüzden yüz milyonlarca row değiştiren tek transaction yerine kontrollü batch yaklaşımı bazı sistemlerde log büyümesini ve recovery süresini daha yönetilebilir hâle getirebilir.

Log Flush

Commit aşamasında durability garantisi için gerekli log kayıtlarının kalıcı storage'a yazılması gerekir. Bu işlem storage latency nedeniyle transaction response süresinin önemli bir bölümünü oluşturabilir. Birçok database group commit benzeri optimizasyonlarla birden fazla transaction'ın flush maliyetini paylaşabilir. Ancak write cache veya storage acknowledgement güvenilir değilse database'in aldığı başarı yanıtı gerçekte fiziksel kalıcılığı garanti etmeyebilir. Kritik sistemlerde storage altyapısının database durability varsayımlarıyla uyumlu olduğunun doğrulanması, yalnızca benchmark sonucu yüksek IOPS elde etmekten daha önemlidir.

Commit Record

Commit record transaction'ın başarıyla tamamlandığını ifade eden kritik log bilgisidir. Crash recovery sırasında engine transaction'ın gerçekten commit edilip edilmediğini bu tür kayıtlarla ilişkilendirerek değerlendirebilir. Uygulama tarafında SQL komutunun çalışmış görünmesi commit record oluştuğu anlamına gelmeyebilir, çünkü bağlantı veya server arızası tam bu sınırda meydana gelebilir. Bu nedenle uygulamalar timeout sonrasında işlemin kesinlikle başarısız olduğunu varsaymamalıdır. Özellikle ödeme ve sipariş sistemlerinde idempotency key veya transaction durum sorgulama mekanizması, commit sonucu belirsiz kalan network hatalarını güvenli yönetmek için önemlidir.

Client'a Başarı Yanıtı

Database gerekli durability koşullarını sağladıktan sonra client'a transaction'ın başarıyla tamamlandığı yanıtını verir. Uygulama bu yanıtı aldıktan sonra işlemin kalıcı olduğunu varsayar. Ancak response network üzerinde kaybolursa database commit etmişken application hata görmüş olabilir. Bu durum aynı isteğin tekrar gönderilmesi hâlinde duplicate transaction riskini doğurur. Veri kurtarma perspektifinde application log ile transaction log zamanlarının karşılaştırılması bu belirsiz olayları anlamaya yardımcı olabilir. İş açısından kritik işlemlerde yalnızca HTTP retry davranışına güvenmek yerine idempotent transaction tasarımı kullanılmalıdır.

Data Page'in Daha Sonra Diske Yazılması

Commit tamamlandıktan sonra dirty data page bir süre buffer cache içinde kalabilir. Database engine uygun checkpoint veya background flush anında page'i kalıcı data file'a yazar. Server bu işlemden önce kapanırsa WAL veya transaction log içindeki kayıtlar restart sırasında değişikliği yeniden oluşturabilir. Bu mekanizma yüksek transaction performansının temel nedenlerinden biridir. Yine de çok fazla dirty page birikmesi checkpoint sırasında yoğun IO oluşturabileceği için database tuning yalnızca log write performansına değil page flushing davranışına da birlikte bakmalıdır.

REDO ve UNDO Nedir?

REDO ve UNDO database recovery mantığının iki farklı yönünü anlatır. REDO tamamlanmış olması gereken değişikliğin crash sonrasında data file üzerinde eksik olması durumunda ileri doğru tekrar uygulanmasını sağlar. UNDO ise tamamlanmamış veya geri alınması gereken transaction etkilerini kaldırmaya yardımcı olur. Her database aynı fiziksel yapıyı veya aynı terminolojiyi kullanmasa da temel fikir committed ve uncommitted durumları doğru ayırmaktır. Recovery motoru log kayıtlarını kör biçimde yeniden çalıştırmaz, transaction sınırları ve database tutarlılık bilgileriyle birlikte değerlendirir. Böylece sistem crash sonrasında application'ın daha önce başarıyla gördüğü committed işlemleri korurken yarım kalmış transaction'ları tutarlı biçimde ortadan kaldırabilir.

REDO: İşlemi İleri Doğru Yeniden Uygulama

REDO, log kaydında bulunan değişikliğin data page üzerinde henüz görünmediği durumda yeniden uygulanmasını ifade eder. Örneğin transaction commit olmuş ancak ilgili dirty page crash öncesinde diske yazılamamış olabilir. Restart sırasında engine logu okuyarak bu committed değişikliği yeniden page üzerine uygular. Aynı kaydın zaten disk üzerinde bulunması durumunda database'in recovery algoritması sequence ve page bilgilerini kullanarak gereksiz veya yanlış tekrarları önler. REDO kavramı PITR sürecinde de önemlidir, çünkü base backup sonrasında oluşan değişiklikler log replay yoluyla hedef zamana kadar ileri taşınır.

UNDO: Tamamlanmamış İşlemi Geri Alma

UNDO tamamlanmamış transaction'ın etkilerini geçersiz kılmak için kullanılır. Server crash anında uzun bir transaction bir kısım değişikliği memory veya data structure üzerinde gerçekleştirmiş fakat commit etmemiş olabilir. Database restart sırasında bu transaction'ın committed olmadığını belirler ve gerekli etkileri ortadan kaldırır. Bazı engine'ler bunun için özel undo kayıtları veya MVCC version mekanizmaları kullanır. Kullanıcı açısından önemli sonuç şudur: crash sonrasında database'in açılması yalnızca logların ileri uygulanması değildir, tamamlanmamış transaction'ların oluşturduğu tutarsızlığın da güvenli biçimde temizlenmesini gerektirir.

Committed Transaction

Committed transaction database'in başarıyla tamamlandığını kabul ettiği işlem birimidir. Crash recovery sırasında bu işlem data file üzerinde eksikse log bilgisi kullanılarak yeniden uygulanması gerekir. Aksi hâlde client'a başarı bildirilen verinin kaybolması durability garantisini ihlal eder. PITR sırasında ise recovery target'ın hangi committed transaction'a kadar ilerlediği özellikle önemlidir. Timestamp kullanıldığında aynı saniyede birden fazla commit olabileceği için olay analizinde LSN, GTID veya database'e özgü daha kesin transaction koordinatları mümkün olduğunda daha güvenilir sınır belirlemeye yardımcı olabilir.

Uncommitted Transaction

Uncommitted transaction crash veya rollback anında tamamlanmamış işlem birimidir. İçindeki bazı değişiklikler buffer veya storage üzerinde iz bırakmış olsa bile kullanıcı açısından kalıcı kabul edilmemelidir. Recovery motoru bu etkileri geri alır veya görünmez hâle getirir. Uzun transaction'lar çok fazla log alanı tutabileceği ve recovery sırasında işlenecek veri miktarını artırabileceği için operasyonel risk oluşturabilir. Database monitoring içinde yalnızca transaction sayısını değil uzun süre açık kalan transaction'ların yaşını, log tüketimini ve blocking etkisini izlemek bu nedenle önemlidir.

Roll-Forward ve Rollback

Roll-forward base backup'tan sonraki log kayıtlarını ileri doğru uygulayarak database'i daha yeni duruma getirme işlemidir. Rollback ise transaction veya recovery bağlamında istenmeyen ve tamamlanmamış değişiklikleri geri alma anlamında kullanılır. PITR çoğu zaman eski backup'ı açıp logları hedef noktaya kadar roll-forward ederek gerçekleştirilir. Bu nedenle point-in-time recovery kavramı günlük dilde “database'i geriye almak” olarak söylense de teknik işlem büyük ölçüde eski bir başlangıç noktasından ileri doğru log replay yapmaktır. Bu ayrım recovery süresinin neden log miktarından doğrudan etkilendiğini de açıklar.

Database Crash Recovery Nasıl Çalışır?

Database crash recovery beklenmeyen kapanış sonrasında engine'in kendi transaction tutarlılığını otomatik olarak yeniden kurduğu süreçtir. Server elektrik kesintisi, işletim sistemi hatası veya process crash nedeniyle normal shutdown gerçekleştirememiş olabilir. Memory içindeki bazı dirty page'ler kaybolur ancak kalıcı log kayıtları hangi işlemlerin güvenle tamamlandığını gösterir. Startup sırasında engine gerekli logları replay eder ve tamamlanmış transaction'ları korurken tamamlanmamış işlemleri temizler. Bu süreç backup restore değildir. Disk üzerindeki database file'ları sağlam olduğu sürece engine mevcut dosyaları log bilgisiyle consistent state'e getirir ve kullanıcı erişimine açar.

Ani Sunucu Kapanması

Ani shutdown sırasında database normal checkpoint ve clean shutdown adımlarını tamamlayamayabilir. Memory içindeki dirty page'lerin bir bölümü data file'a henüz yazılmamış olabilir. Buna rağmen committed transaction'ların log kayıtları güvenli storage üzerinde bulunuyorsa engine bu değişiklikleri restart sırasında yeniden oluşturabilir. Sorunun fiziksel disk kaybı veya data file corruption olması hâlinde crash recovery tek başına yeterli olmayabilir. Bu yüzden crash recovery ile backup tabanlı disaster recovery planları birbirini tamamlayan ancak farklı failure scenario'larını çözen iki ayrı güvenlik katmanı olarak tasarlanmalıdır.

Buffer'daki Dirty Page'ler

Crash meydana geldiğinde volatile memory kaybolduğu için buffer cache içindeki dirty page'ler de kaybolur. Disk üzerindeki data page bu durumda son flush edildiği eski hâlde olabilir. Database log kayıtları committed değişikliklerin yeniden uygulanmasına imkân sağlayarak bu farkı kapatır. Eğer log storage da aynı anda bozulmuşsa veri kaybı riski artar. Bu nedenle transaction log'un data disk ile aynı fiziksel failure domain'de tutulması, özellikle yüksek kritik sistemlerde correlated failure riskini yükseltebilir ve storage mimarisi buna göre değerlendirilmelidir.

Log Replay

Log replay engine'in kalıcı transaction log kayıtlarını okuyup gerekli database değişikliklerini yeniden uygulamasıdır. Başlangıç noktası son checkpoint veya database'e özgü recovery metadata üzerinden belirlenebilir. Log miktarı arttıkça startup recovery süresi de uzayabilir. Bu nedenle çok uzun transaction, aşırı log generation veya yetersiz checkpoint düzeni RTO üzerinde beklenmedik etki oluşturabilir. Production ortamında crash recovery süresini hiç ölçmemek, teorik RTO hedefini gerçek sistem davranışından koparır. Kontrollü failure testleri bu süreyi anlamak için yararlı olabilir.

Committed Transaction'ların REDO Edilmesi

Commit edilmiş transaction'ın değişiklikleri disk page üzerinde henüz yer almıyorsa recovery sırasında REDO uygulanabilir. Amaç client'ın daha önce başarı olarak gördüğü işlemin korunmasıdır. Engine log sırası ve page sequence bilgilerini kullanarak yalnızca gerekli değişiklikleri uygular. Recovery tamamlanmadan database'in normal write trafiğine açılması tutarlılık riskine yol açabileceği için engine başlangıç prosedürü bu aşamayı kontrollü yönetir. Yüksek log hacmine sahip database'lerde replay throughput metriğini ölçmek, crash recovery ve PITR RTO hesaplamalarının daha gerçekçi yapılmasına yardımcı olur.

Incomplete Transaction'ların Geri Alınması

Crash anında commit edilmemiş transaction'lar kalıcı sonuç olarak bırakılmamalıdır. Database gerekli undo veya transaction visibility mekanizmalarını kullanarak bu etkileri temizler. Çok uzun bir transaction crash öncesinde büyük miktarda data değiştirmişse rollback aşaması recovery süresini uzatabilir. Bu durum özellikle büyük migration veya batch süreçlerinde gözden kaçabilir. Uygulama ekibi uzun işlemleri daha küçük transaction bloklarına bölmeyi değerlendirirken business atomicity ihtiyacını da korumalıdır. Yalnızca log büyümesini azaltmak için transaction bütünlüğünden vazgeçmek doğru yaklaşım değildir.

Database'in Consistent State'e Getirilmesi

Crash recovery'nin nihai amacı database'i transaction kuralları açısından tutarlı bir state'e getirmektir. Committed işlemler korunmalı, tamamlanmamış işlemler geçersiz kılınmalı ve page ile log sequence ilişkileri uyumlu olmalıdır. Bu işlem tamamlandıktan sonra database normal client bağlantılarını kabul etmeye başlayabilir. Recovery başarılı olması uygulama verisinin iş açısından doğru olduğu anlamına gelmez, çünkü kullanıcı tarafından commit edilmiş hatalı DELETE de tutarlı bir transaction'dır. Logical corruption durumunda ayrı PITR veya selective recovery prosedürü gerektiği için teknik consistency ile business correctness birbirinden ayrılmalıdır.

Crash Recovery ile Veri Kurtarma Arasındaki Fark

Crash recovery database'in ani kapanış sonrasında mevcut data file ve logları kullanarak otomatik biçimde ayağa kalkmasıdır. Veri kurtarma ise silinen, bozulan veya kaybolan veriyi backup, archive, replica veya başka kaynaklardan yeniden elde etmeyi kapsayan daha geniş süreçtir. Database düzgün açıldığı hâlde bir kullanıcı yanlışlıkla bütün siparişleri DELETE etmiş olabilir ve crash recovery bu işlemi geri almaz. Çünkü hata transaction açısından geçerli biçimde commit edilmiştir. Bu durumda PITR veya selective restore gerekir. Dolayısıyla “database açıldı” ifadesi ile “veri doğru durumda” ifadesi recovery runbook içinde iki ayrı doğrulama aşaması olarak ele alınmalıdır.

Otomatik Startup Recovery

Startup recovery database process yeniden başladığında engine tarafından otomatik yürütülen crash recovery sürecidir. Genellikle DBA'nın full backup seçip manuel restore yapması gerekmez. Engine mevcut data file ve transaction log yapılarını analiz eder. Gerekli REDO ve UNDO işlemlerinden sonra database normal çalışma durumuna gelir. Süre database büyüklüğünden çok son checkpoint sonrası işlenecek log miktarı ve transaction durumlarından etkilenebilir. Uzun startup recovery olayları monitoring tarafından sıradan servis açılışı gibi değil RTO açısından ölçülmesi gereken operasyonel veri olarak kaydedilmelidir.

Backup Restore

Backup restore mevcut database dosyaları kullanılamadığında veya belirli eski state'e dönmek gerektiğinde yedek kopyadan veri oluşturma işlemidir. Full, differential, incremental veya fiziksel base backup türleri database teknolojisine göre farklılık gösterir. Restore tek başına hedeflenen en son zamana ulaşmayı garanti etmez. Transaction log, WAL veya binlog replay gerekiyorsa backup yalnızca başlangıç noktasıdır. Restore süresinin büyük database'lerde saatler sürmesi mümkün olduğu için RTO hesabında backup dosyasını storage'dan recovery ortamına taşıma süresi de dahil edilmelidir.

Point-in-Time Recovery

PITR database'i belirli bir zaman veya transaction koordinatındaki state'e getirmeyi hedefler. Genellikle olaydan önceki uygun backup restore edilir ve daha sonraki log kayıtları recovery target'a kadar uygulanır. Yanlış DELETE, UPDATE veya migration bunun yaygın kullanım alanlarıdır. Recovery target olayın hemen öncesi olmalı ve production'a geçmeden önce read-only doğrulama yapılmalıdır. Ayrı recovery instance kullanmak mevcut production state'ini koruyarak forensic analiz, karşılaştırma ve selective data recovery seçeneklerini açık tutar.

Logical Corruption Recovery

Logical corruption database dosyasının fiziksel olarak sağlıklı olduğu ancak verinin iş açısından yanlış duruma geldiği senaryodur. Hatalı DELETE, bozuk migration veya application bug buna örnek verilebilir. Replication bu hatayı genellikle replica'lara da taşıdığı için tek başına çözüm değildir. PITR ile olaydan önceki state ayrı bir instance üzerinde oluşturulabilir. Ardından yalnızca ihtiyaç duyulan kayıtlar production'a taşınabilir. Böylece hatalı transaction sonrasında gerçekleşen doğru işlemleri kaybetmeden daha kontrollü bir reconciliation süreci yürütmek mümkün olur.

Physical Corruption Recovery

Physical corruption data file, page veya storage yapısının okunamaz ya da tutarsız hâle gelmesini ifade eder. Disk arızası, storage controller problemi veya donanım hatası buna neden olabilir. Crash recovery bazı sınırlı problemleri çözebilse de ciddi physical corruption backup restore gerektirebilir. Checksum verification ve database'in kendi consistency araçları problemi tespit etmeye yardımcı olur. Recovery runbook hangi noktada repair yaklaşımından vazgeçilip sağlam backup ve log zinciri üzerinden yeni instance oluşturulacağını açık biçimde tanımlamalıdır.

Checkpoint Nedir?

Checkpoint database'in recovery için referans noktası oluşturduğu ve dirty data page'lerin kalıcı storage'a yazılmasını düzenlediği mekanizmadır. Amaç her crash sonrasında logun en başından replay edilmesini önlemektir. Checkpoint ilerledikçe recovery'nin dikkate alması gereken eski değişikliklerin önemli bölümü data file üzerinde güvenli hâle gelir. Ancak checkpoint backup değildir ve tek başına geçmiş bir zamana dönme yeteneği sağlamaz. Benzer biçimde checkpoint gerçekleşmesi bütün transaction log dosyalarının otomatik olarak silineceği anlamına gelmez. Log truncation ve archive retention davranışı database'in recovery modeli, replica ihtiyacı ve backup durumuna bağlı olarak farklı kurallarla yönetilir.

Checkpoint'in Amacı

Checkpoint recovery başlangıç noktasını ilerleterek crash sonrasında işlenecek log miktarını azaltmayı hedefler. Aynı zamanda dirty page'lerin kontrollü biçimde disk file'lara yazılmasını düzenler. Çok seyrek checkpoint daha uzun recovery süresi oluşturabilirken aşırı sık checkpoint yoğun write IO yaratabilir. Database engine bu dengeyi workload'a göre otomatik olarak yönetmeye çalışır. DBA tuning yaparken yalnızca daha kısa recovery hedeflememeli, checkpoint'in normal transaction latency ve storage throughput üzerindeki etkisini de birlikte ölçmelidir.

Dirty Page'lerin Diske Yazılması

Checkpoint sırasında database belirli dirty page'leri kalıcı storage'a yazar. Bu işlem memory ile disk arasındaki veri farkını azaltır. Page flush yoğunluğu kısa sürede çok yükselirse storage queue ve query latency değerleri etkilenebilir. Modern engine'ler yazma yükünü zamana yaymaya çalışır. Transaction log diskleri ile data diskleri aynı kaynakları paylaşıyorsa checkpoint IO ile log flush IO birbirini etkileyebilir. Bu nedenle storage monitoring içinde write latency, queue depth ve checkpoint davranışı birlikte değerlendirilmelidir.

Recovery Süresinin Azaltılması

Checkpoint'in en önemli operasyonel faydalarından biri crash recovery sırasında işlenecek eski log miktarını azaltmaktır. Data page'ler güncel hâle geldikçe engine daha yakın bir recovery başlangıç noktası kullanabilir. Bu durum özellikle yüksek transaction hacminde RTO üzerinde belirgin etki yaratır. Yine de recovery süresini yalnızca checkpoint interval değerinden hesaplamak doğru değildir. Long-running transaction, storage hızı ve log replay throughput da önemli faktörlerdir. Gerçek crash veya restore drill sonuçları teorik ayarlardan daha güvenilir RTO verisi sağlar.

Checkpoint Backup mıdır?

Hayır, checkpoint backup değildir. Checkpoint production database'in mevcut disk dosyalarını daha güncel ve recoverable state'e taşımaya yardımcı olur. Disk tamamen kaybolursa aynı disk üzerindeki checkpoint bilgisi veriyi geri getiremez. Backup ise failure domain dışında korunabilen ayrı bir veri kopyası sağlar. Point-in-time recovery için ayrıca log archive veya log backup zinciri gerekir. Bu ayrım özellikle “database checkpoint alıyor, ayrıca backup gerekmiyor” gibi riskli varsayımların önüne geçmek açısından önemlidir.

Checkpoint Logları Siler mi?

Checkpoint ile log truncation aynı işlem değildir. Checkpoint bazı database ve recovery modellerinde log alanının yeniden kullanılabilir hâle gelmesine katkıda bulunabilir, ancak gerekli log kayıtları replica, backup veya aktif transaction nedeniyle tutulmaya devam edebilir. SQL Server FULL recovery modelinde transaction log backup alınmaması log büyümesinin yaygın nedenlerinden biridir. PostgreSQL tarafında replication slot veya archiving problemi eski WAL segmentlerinin tutulmasına yol açabilir. Bu nedenle log disk dolduğunda çözüm olarak checkpoint zorlamak yerine gerçek retention nedenini database'e özgü monitoring bilgisiyle tespit etmek gerekir.

Log Sequence Number (LSN) Nedir?

LSN log içindeki belirli konumu ifade eden sıralı koordinattır. Database engine hangi log kaydının önce veya sonra olduğunu bu tür sequence bilgileriyle takip eder. Recovery, replication ve backup zincirinde LSN benzeri koordinatlar timestamp'ten daha kesin sınırlar sunabilir. Farklı database teknolojileri aynı kavramı aynı biçimde uygulamaz. SQL Server ve PostgreSQL LSN kullanırken MySQL binlog file position ve GTID, Oracle ise SCN gibi farklı koordinat modellerine sahiptir. Recovery runbook bu değerlerin olay sırasında nereden alınacağını ve hangi formatta kaydedileceğini önceden tanımlamalıdır.

SQL Server LSN

SQL Server LSN transaction log kayıtlarının sırasını belirleyen tanımlayıcıdır. Full, differential ve log backup dosyalarının hangi log aralığını kapsadığını anlamak için kullanılır. Restore sequence oluşturulurken log backup'ların doğru sırada ve kesintisiz uygulanması LSN zinciriyle ilişkilidir. Missing backup veya yanlış başlangıç noktası restore işleminin ilerlemesini engelleyebilir. Incident sırasında backup metadata'sını toplamak ve hangi file'ın FirstLSN, LastLSN gibi değerleri kapsadığını belgelemek recovery süresini azaltan önemli DBA pratiğidir.

PostgreSQL LSN

PostgreSQL LSN WAL içindeki byte konumunu ifade eder ve yeni WAL kayıtları üretildikçe ilerler. Replication lag hesaplama ve recovery progress ölçme gibi alanlarda kullanılabilir. PITR sırasında recovery_target_lsn ile belirli WAL konumuna kadar replay yapılabilir. LSN timestamp'e göre daha deterministik sınır sunabilir ancak olay anındaki doğru LSN değerini elde etmek için önceden observability ve kayıt mekanizması gerekir. Deployment öncesi named restore point oluşturmak bazı operasyonlarda insan tarafından yorumlanan zaman bilgisinden daha güvenilir recovery marker sağlayabilir.

MySQL Binlog Position

MySQL binary log position belirli binlog dosyası içindeki event konumunu ifade eder. PITR sırasında mysqlbinlog aracına başlangıç ve bitiş position bilgileri verilerek belirli event aralığı seçilebilir. Timestamp'e göre position kullanmak aynı saniyede gerçekleşen çok sayıda transaction arasında daha kesin kontrol sağlayabilir. Ancak file rotation nedeniyle position tek başına yeterli değildir, ilgili binary log file adıyla birlikte kaydedilmelidir. Backup metadata'sına doğru binlog file ve position eklemek recovery runbook'un hangi noktadan log replay başlatacağını güvenilir biçimde belirlemesine yardımcı olur.

GTID

GTID MySQL replication ortamlarında transaction'a global olarak benzersiz kimlik vermeyi amaçlar. Kaynak değişse bile belirli transaction'ın uygulanıp uygulanmadığını takip etmeyi kolaylaştırabilir. Recovery ve replication prosedürlerinde GTID setleri hangi işlemlerin mevcut olduğunu daha açık ifade edebilir. Buna rağmen yanlış GTID reset veya purge işlemleri recovery geçmişini bozabilir. Production runbook içinde GTID lifecycle, binary log retention ve backup metadata birlikte ele alınmalı, bakım sırasında log geçmişini temizleyen komutlar yalnızca etkileri tamamen anlaşılmışsa uygulanmalıdır.

Oracle SCN

Oracle SCN database değişikliklerinin mantıksal zaman sırasını takip etmek için kullanılan system change number değeridir. Recovery ve consistency işlemlerinde önemli referans noktası sağlar. Timestamp üzerinden yapılan recovery de arka planda SCN ilişkileriyle çözümlenebilir. Belirli deployment veya business event için SCN kaydı almak daha kesin recovery hedefi oluşturabilir. Diğer database koordinatlarında olduğu gibi SCN değerinin tek başına bulunması yeterli değildir, onu kapsayan backup ve archived redo zincirinin de eksiksiz olması gerekir.

Recovery'de Log Koordinatlarının Önemi

Recovery target belirlerken yalnızca “yaklaşık 14:05” bilgisine güvenmek risklidir. Aynı saniyede yüzlerce transaction commit etmiş olabilir ve server saatleri arasında fark bulunabilir. LSN, binlog position, GTID veya SCN gibi database'e özgü koordinatlar hedefi daha deterministik hâle getirir. En iyi yaklaşım deployment ve kritik business event'leri bu koordinatlarla otomatik ilişkilendirmektir. Böylece incident anında DBA ekipleri log içinde manuel tahmin yapmak yerine önceden kaydedilmiş recovery marker üzerinden daha güvenli restore gerçekleştirebilir.

Transaction Log Backup Nedir?

Transaction log backup, belirli database sistemlerinde full backup sonrasında oluşan transaction log kayıtlarının ayrı yedekler hâlinde korunmasını sağlar. SQL Server FULL recovery modelinde düzenli log backup PITR stratejisinin merkezindedir. Log backup full backup'ın yerine geçmez, çünkü recovery için başlangıçta uygun data backup gerekir. Benzer biçimde differential backup ile log backup farklı amaçlara hizmet eder. Log backup sıklığı RPO üzerinde doğrudan etkilidir, çünkü son sağlam log backup'tan sonra tail-log alınamıyorsa bu aralıkta gerçekleşen işlemler kaybedilebilir. Bu nedenle backup schedule iş biriminin kabul ettiği veri kaybı hedefinden türetilmelidir.

Full Backup ile Log Backup Arasındaki Fark

Full backup database'in belirli bir anda restore edilebilir geniş veri kopyasını sağlar. Log backup ise belirli transaction log aralığını korur ve base backup sonrasında database'i daha ileri zamana taşımaya yardımcı olur. Yalnızca log backup dosyalarıyla sıfırdan database restore etmek çoğu standart senaryoda mümkün değildir. Bunun için restore zincirinin uygun full backup'tan başlaması gerekir. Full backup sıklığını artırmak restore başlangıç dosyasını daha güncel yapabilir ancak log backup sıklığına göre farklı RPO ve storage etkisi oluşturur. İki backup türü birbirini tamamlayan parçalar olarak tasarlanmalıdır.

Differential Backup ile Log Backup Arasındaki Fark

Differential backup son full backup'tan beri değişen data extent veya page'lerini içeren daha geniş veri kopyasıdır. Log backup ise transaction log'un belirli sıralı aralığını korur. Differential backup restore sırasında uygulanması gereken log miktarını azaltarak RTO'yu iyileştirebilir. Ancak PITR hedefinin ince ayrıntısı yine transaction log zincirine bağlı olabilir. Backup stratejisi yalnızca en küçük dosya boyutunu hedeflememeli, full restore, differential restore ve log replay sürelerini gerçek drill ile karşılaştırarak toplam RTO açısından en uygun kombinasyonu seçmelidir.

Log Backup Ne Sıklıkla Alınmalı?

Tek bir doğru log backup sıklığı yoktur. Frekans business RPO hedefinden, transaction hacminden ve backup altyapısının kapasitesinden türetilmelidir. Beş dakikalık RPO isteyen SQL Server sistemi saatte bir log backup alıyorsa tasarım hedefle uyumlu değildir. Çok sık backup daha fazla dosya ve operasyon oluşturabilir ancak veri kaybı penceresini küçültür. Gerçek sıklık belirlenirken tail-log alınamayan felaket senaryosu temel varsayım olarak kullanılmalı ve backup job gecikmesi için ayrıca güvenlik payı bırakılmalıdır.

Log Backup Frekansı RPO'yu Nasıl Etkiler?

RPO kabul edilebilir maksimum veri kaybı süresini ifade eder. On dakikada bir log backup alınıyorsa ve sistem tamamen kaybedildiğinde tail-log erişilemiyorsa teorik veri kaybı penceresi yaklaşık bu aralığa yaklaşabilir. Ancak backup job'ın geç başlaması, upload süresi veya archive failure gerçek RPO'yu kötüleştirebilir. Bu nedenle yalnızca schedule değerini değil son başarılı log backup zamanını ve logun güvenli uzak storage'a ulaştığı zamanı izlemek gerekir. RPO dashboard'u planlanan hedef ile ölçülen gerçek koruma noktasını ayrı değerler olarak göstermelidir.

Log Chain Nedir?

Log chain base backup ile başlayıp recovery target'a kadar gereken transaction log kayıtlarının kesintisiz biçimde bulunmasını ifade eder. Zincirin ortasında eksik bir parça varsa sonraki log dosyaları mevcut olsa bile recovery hedefe ilerleyemeyebilir. Bu nedenle backup dosyasının başarılı oluşturulması tek başına yeterli değildir. Dosyaların sırası, bütünlüğü ve ilgili base backup ile ilişkisi düzenli olarak doğrulanmalıdır. SQL Server log backup zinciri bu kavramın belirgin örneğidir, PostgreSQL WAL archive ve MySQL binlog retention içinde de benzer biçimde kesintisiz değişiklik geçmişine ihtiyaç vardır. Recoverability monitoring bu sürekliliği aktif olarak kontrol etmelidir.

Full/Base Backup

Full veya base backup recovery zincirinin veri başlangıç noktasıdır. Seçilen backup recovery target'tan önce tamamlanmış ve gerekli log aralığıyla uyumlu olmalıdır. En yeni backup her zaman doğru seçim olmayabilir, çünkü hedef zaman backup'ın kapsadığı başlangıç durumundan daha eski olabilir. Backup metadata'sı log başlangıç koordinatını ve recovery için gerekli diğer bilgileri taşımalıdır. Recovery automation uygun backup'ı manuel dosya adına göre değil metadata ve target bilgisine göre seçerse insan hatası riski önemli ölçüde azalır.

İlk Log Koordinatı

Base backup'ın hangi log noktasından itibaren recovery gerektirdiği bilinmelidir. SQL Server LSN, PostgreSQL WAL range veya MySQL binlog file position gibi koordinatlar bu ilişkiyi kurar. Backup alınırken koordinat otomatik metadata içine yazılmalıdır. Operatörün olay sırasında “bu backup yaklaşık gece ikide alındı” bilgisine dayanması risklidir. Doğru başlangıç koordinatı bilindiğinde recovery engine hangi log segmentlerinin gerçekten gerekli olduğunu kesin biçimde belirleyebilir ve gereksiz dosya arama süresini azaltabilir.

Ardışık Log Backup'ları

Base backup'tan sonra gerçekleşen değişikliklerin hedef zamana kadar eksiksiz ilerlemesi için log parçaları ardışık olmalıdır. Bir log backup dosyasının kaybolması restore zincirini kırabilir. Daha sonraki backup dosyalarının bulunması missing interval sorununu otomatik çözmez. Bu yüzden backup repository dosya varlığını, checksum değerlerini ve sequence aralıklarını düzenli taramalıdır. Restore drill sırasında rastgele recovery target seçmek yalnızca son backup'ın değil bütün zincirin gerçek kullanımda çalıştığını test etmek için çok daha güçlü bir yöntemdir.

Recovery Point

Recovery point database'in geri getirilebildiği belirli transaction veya zaman sınırıdır. En son recovery point son alınan backup zamanı ile aynı olmak zorunda değildir. Continuous WAL archive veya sık log backup varsa çok daha güncel noktaya ulaşılabilir. Replica lag, archive upload gecikmesi ve missing segment bu noktayı geriye çekebilir. Monitoring sisteminin “latest recoverable time” değerini doğrudan hesaplaması, ekiplerin yalnızca yeşil backup job ikonuna bakarak yanlış güven oluşturmasını engeller.

Log Chain Neden Kesintisiz Olmalıdır?

Log replay sıralı değişiklik geçmişine dayanır. Aradaki bir segment eksik olduğunda sonraki kaydın hangi data state üzerine uygulanacağı güvenilir biçimde bilinmeyebilir. Recovery motoru bu nedenle gap bulunan zinciri kabul etmez veya hedefe ulaşamaz. Kesintisiz chain özellikle düşük RPO hedeflerinde kritik öneme sahiptir. Archive sisteminin yalnızca son dosyanın varlığını değil sequence continuity değerini kontrol etmesi gerekir. Missing segment alarmı backup başarısızlığı kadar yüksek öncelikli ele alınmalıdır.

Log Chain Nasıl Bozulur?

Log chain birçok farklı operasyon hatası nedeniyle kullanılamaz hâle gelebilir. Eksik backup, erken silinen WAL veya binlog, bozuk archive dosyası ve yanlış recovery model değişikliği en bilinen örneklerdir. Cloud veya object storage'a upload başarısız olurken local dosyanın retention işlemiyle silinmesi de zincir kaybı oluşturabilir. Bu problemler genellikle gerçek restore gününe kadar fark edilmezse RPO hedefi kâğıt üzerinde kalır. Bu nedenle log chain bütünlüğü backup sürecinden ayrı bir monitoring hedefi olmalıdır. Her segmentin arşivde doğrulandığı ve restore testinde kullanılabildiği ölçülmelidir.

Eksik Log Backup

Planlı log backup'lardan biri alınamaz veya repository'ye ulaşamazsa recovery aralığında boşluk oluşabilir. Sonraki backup'ların başarılı olması ilk hatayı ortadan kaldırmaz. Job monitoring yalnızca son çalışmanın sonucuna bakarsa bu gap gözden kaçabilir. Backup catalog sequence aralıklarını kontrol etmeli ve eksik dosya tespit edildiğinde alarm üretmelidir. Olay erken fark edilirse transaction log hâlâ source üzerinde bulunuyorken ek backup alma imkânı olabilir. Geç fark edilmesi durumunda recovery hedefi kalıcı olarak sınırlanabilir.

Erken Silinen WAL/Binlog

WAL veya binlog retention maliyeti azaltmak amacıyla gereğinden kısa tutulursa geç fark edilen incident için gerekli değişiklik geçmişi kaybolabilir. Örneğin hata üç gün sonra bulunuyor ancak loglar yalnızca bir gün saklanıyorsa iki günlük recovery penceresi kullanılamaz. Retention süresi yalnızca backup frekansına göre belirlenmemelidir. Incident detection süresi, forensic analiz ve recovery hazırlığı için gereken zaman da hesaba katılmalıdır. Archive storage ucuz olduğu için çok uzun tutmak da otomatik olarak doğru değildir, kişisel veri ve KVKK saklama gereksinimleri ayrıca değerlendirilmelidir.

Bozuk Log Segmenti

Archive repository'de dosyanın bulunması onun okunabilir ve bütün olduğunu garanti etmez. Storage corruption, hatalı transfer veya yarım upload nedeniyle log segmenti bozulabilir. Checksum veya provider integrity özellikleri bu tür sorunları erken yakalamaya yardımcı olur. En güçlü doğrulama yine gerçek restore ve replay testidir. Random recovery target kullanan otomatik drill, farklı log segmentlerini zaman içinde gerçekten okuyarak yalnızca file existence kontrolünden çok daha yüksek güven sağlar.

Yanlış Recovery Model

SQL Server'da SIMPLE recovery model kullanmak transaction log backup ve standart point-in-time restore yeteneğini sınırlar. Database'in FULL olması gerektiği düşünülürken yanlışlıkla SIMPLE'a geçirilmesi beklenen log zincirini bozabilir. Recovery model değişiklikleri sıradan configuration değişikliği değil veri koruma politikası değişikliği olarak ele alınmalıdır. Infrastructure veya database policy bu ayarı otomatik doğrulayabilir. Production environment'ta recovery model drift tespit edildiğinde yalnızca config düzeltilmemeli, mevcut backup zincirinin yeniden nasıl güvenli hâle getirileceği de kontrol edilmelidir.

Archive Failure

PostgreSQL archive_command başarısızlığı veya benzer archive pipeline problemi gerekli WAL segmentlerinin uzak repository'ye gitmesini engelleyebilir. Source server bir süre segmentleri local olarak tutabilir ancak disk kapasitesi sonunda yeni risk oluşturur. Monitoring yalnızca disk doluluk alarmı vermemeli, oldest unarchived WAL ve archive failure count gibi doğrudan recoverability metriklerini de izlemelidir. Archive destination geçici olarak erişilemez olduğunda retry davranışı açıkça test edilmelidir. Failover sonrasında yeni primary'nin archive zincirini doğru timeline üzerinden devam ettirmesi de runbook içinde bulunmalıdır.

Retention Süresinin Yetersiz Olması

Retention recovery penceresinin gerçek üst sınırını belirler. Bir haftalık PITR sözü verilen sistemde loglar yalnızca iki gün tutuluyorsa mimari hedef karşılanmaz. Süre belirlenirken backup sıklığı, olay tespit gecikmesi ve iş biriminin talep ettiği geçmiş recovery ihtiyacı dikkate alınmalıdır. Günlük log üretim hacmi storage maliyetini belirlemek için ayrıca ölçülmelidir. Retention policy otomatik lifecycle rule ile uygulanabilir ancak yanlış rule bütün log geçmişini hızla silebileceği için değişiklikler production'a çıkmadan test edilmelidir.

Tail-Log Backup Nedir?

Tail-log backup SQL Server'da son düzenli log backup'tan sonra transaction log içinde kalmış ve henüz yedeklenmemiş kayıtları yakalamayı amaçlar. Database arızalanmış olsa bile log file erişilebilir durumdaysa son commit'leri kaybetmeden recovery zincirini tamamlamaya yardımcı olabilir. Full veya bulk-logged recovery model bağlamında kullanılır. Her restore senaryosunda zorunlu değildir, çünkü hedef recovery point daha eski log backup içinde bulunabilir. Ancak failure anına mümkün olduğunca yakın recovery hedefleniyorsa tail-log alma olasılığı runbook içinde olayın erken aşamasında değerlendirilmelidir. Yanlış restore adımı log tail'in üzerine yazarsa kurtarılabilecek son işlemler kaybolabilir.

Failure Sonrasında Kuyrukta Kalan Loglar

Son planlı transaction log backup'tan sonra yeni transaction'lar oluşmuş olabilir. Server data file tarafında hasar görmüş ancak transaction log dosyası hâlâ okunabiliyorsa bu son kayıtlar tail-log backup ile korunabilir. Bu işlem felaket anındaki RPO'yu önemli ölçüde iyileştirebilir. Recovery ekibi production database üzerinde yeni değişiklik yapmadan önce log tail'in mevcut durumunu değerlendirmelidir. Otomatik incident script'lerinin doğrudan restore başlatması yerine önce tail-log olasılığını kontrol etmesi bu nedenle daha güvenli tasarımdır.

Son Commit'leri Kurtarmak

Son başarılı log backup ile failure zamanı arasındaki committed transaction'lar iş açısından çok değerli olabilir. Tail-log backup bu aralıktaki kayıtları recovery zincirine ekleyerek veri kaybını azaltabilir. Özellikle ödeme, sipariş veya finans sistemlerinde birkaç dakikalık işlem bile yüksek business impact taşıyabilir. Buna rağmen log file fiziksel olarak kaybolmuş veya bozulmuşsa tail alınamayabilir. RPO planı hiçbir zaman tail-log'un kesin alınabileceğini varsaymamalı, en kötü senaryoda son uzak ve doğrulanmış log backup noktasını temel almalıdır.

Tail-Log Ne Zaman Alınabilir?

Tail-log backup için transaction log dosyasının okunabilir olması gerekir. Database data file'ları hasarlı olsa bile bazı koşullarda log tail hâlâ erişilebilir olabilir. Restore başlamadan ve log zinciri üzerine yeni state yazılmadan önce değerlendirilmesi önemlidir. Database tamamen kaybolduysa veya log device zarar gördüyse bu seçenek bulunmayabilir. Bu nedenle transaction log storage'ını data file ile aynı fiziksel failure domain'den ayırmak yalnızca performans değil recovery olasılığı açısından da değerlendirilebilecek bir tasarım kararıdır.

Tail-Log Backup'ın RPO'ya Etkisi

Tail-log başarıyla alınabilirse RPO son planlı log backup zamanından failure anına çok daha yakın noktaya taşınabilir. Ancak bunun gerçekleşeceği garanti değildir. Storage tamamıyla kaybolduğunda son güvenli archive kopyası gerçek recovery sınırı olur. Bu yüzden RPO raporlamasında “planlanan log backup interval” ile “latest off-host recoverable point” ayrı değerler olarak gösterilmelidir. Tail-log potansiyel bir iyileştirme olarak görülmeli, temel veri koruma stratejisinin yerine kullanılmamalıdır.

Point-in-Time Recovery (PITR) Nedir?

Point-in-Time Recovery database'i geçmişte seçilen belirli bir noktadaki tutarlı duruma getirme işlemidir. En yaygın yöntem uygun base backup restore ettikten sonra transaction log, WAL veya binlog kayıtlarını hedef noktaya kadar replay etmektir. PITR özellikle yanlış DELETE, yanlış UPDATE, bozuk migration ve application bug gibi mantıksal veri hatalarında çok değerlidir. Amaç her zaman production database'in tamamını geriye döndürmek değildir. Çoğu olayda ayrı recovery instance oluşturup doğru kayıtları oradan production'a taşımak daha güvenli olabilir. İşlem Günlükleri (Transaction Logs) ve Veri Kurtarma stratejisinin gerçek değeri, doğru işlemleri koruyup yalnızca hatanın etkisini giderebildiğiniz bu kontrollü senaryolarda ortaya çıkar.

PITR Hangi Problemleri Çözer?

PITR database fiziksel olarak çalışmaya devam ederken business açısından yanlış değişiklik oluştuğu senaryolarda güçlü bir kurtarma seçeneğidir. Hatalı SQL, bozuk deployment veya uygulama hatası transaction olarak başarıyla commit edilmiş olabilir. Crash recovery bu işlemi geçerli kabul ettiği için otomatik biçimde geri almaz. PITR geçmişteki doğru state'i yeniden oluşturarak karşılaştırma ve selective recovery imkânı sunar. Bunun çalışabilmesi için olaydan önce başlayan geçerli base backup ve hedef noktaya kadar kesintisiz log geçmişi gerekir. Bu nedenle PITR özelliği olay anında açılan bir seçenek değil önceden tasarlanması gereken veri koruma kabiliyetidir.

Yanlış DELETE

Yanlış DELETE en klasik PITR senaryolarından biridir. Transaction commit edildikten sonra normal ROLLBACK kullanılamaz. Database'i silme işleminden önceki noktaya restore etmek kayıp kayıtların yeniden elde edilmesini sağlar. Fakat olaydan sonra doğru transaction'lar gerçekleşmişse production'ı tamamen geriye almak yeni veri kaybı oluşturabilir. Bu nedenle recovery instance üzerinde eski kayıtları çıkarıp production'a kontrollü şekilde geri eklemek birçok durumda daha uygun yaklaşımdır. Reconciliation sırasında foreign key, sequence ve bağlı tablolardaki etkiler de birlikte kontrol edilmelidir.

Yanlış UPDATE

WHERE koşulu unutulan bir UPDATE binlerce veya milyonlarca kaydı birkaç saniyede değiştirebilir. Transaction commit olduktan sonra yanlış eski değerleri uygulama tablosundan doğrudan bulmak mümkün olmayabilir. PITR ile hata öncesi state ayrı ortamda oluşturulur. Production ile recovery instance arasındaki fark karşılaştırılarak hangi row'ların etkilendiği belirlenebilir. Güncellemeden sonra oluşan geçerli değişiklikler korunacaksa yalnızca gerekli kolonların geri taşınması gerekebilir. Bu süreç business owner doğrulamasıyla yürütülmeli ve otomatik script production'a uygulanmadan önce dry-run sonucu incelenmelidir.

Hatalı Migration

Schema veya data migration yanlış çalıştığında etkisi yalnızca birkaç row ile sınırlı kalmayabilir. Column transformation, type conversion veya toplu cleanup işlemi geri döndürülemez veri kaybı oluşturabilir. Deployment öncesi backup ve named recovery marker kullanmak incident sırasında doğru hedefi hızlı belirlemeye yardımcı olur. Uygulama rollback edilse bile database state geri dönmediği için migration recovery ayrı planlanmalıdır. CI/CD pipeline deployment ID, migration version ve database recovery koordinatını aynı kayda eklerse olay ile recovery target arasındaki ilişki daha güvenilir kurulabilir.

Uygulama Bug'ı

Application bug uzun süre boyunca yanlış veri üretebilir veya mevcut kayıtları bozabilir. Sorun tek bir transaction ile sınırlı değilse recovery target seçmek daha zordur. İlk hatalı transaction'ın zamanı veya sequence koordinatı belirlenmelidir. PITR eski doğru state'i oluşturabilir ancak bug sonrasında gerçekleşen yüzlerce geçerli business işleminin nasıl korunacağı ayrıca analiz edilmelidir. Selective recovery ve reconciliation bu tür olaylarda full rollback'ten daha değerli olabilir. Root cause düzeltilmeden restore edilen data tekrar aynı bug tarafından bozulabileceği için application fix ve data recovery koordineli yürütülmelidir.

Veri Corruption

Logical corruption uygulama veya kullanıcı işlemleriyle, physical corruption ise storage ve page seviyesinde farklı nedenlerle oluşabilir. PITR logical corruption için geçmişteki sağlam state'e dönmeyi sağlar. Physical corruption durumunda sağlam backup seçimi ve log replay ile database farklı storage üzerinde yeniden oluşturulabilir. Her iki durumda da corruption başlangıç zamanı doğru belirlenmezse hatalı veri yeniden replay edilerek restore edilen instance'a taşınabilir. Recovery validation bu nedenle yalnızca database açıldı mı kontrolünden ibaret olmamalı, olayın etkilediği kritik tabloların business doğruluğunu da test etmelidir.

PITR'ın Temel Bileşenleri

Başarılı PITR için dört temel parça gerekir: uygun base backup, kesintisiz transaction log geçmişi, açık recovery target ve bu kayıtları doğru sırayla uygulayan replay mekanizması. Bu parçalardan biri eksikse hedef noktaya ulaşmak mümkün olmayabilir. Base backup çok eskiyse replay süresi uzar ve RTO kötüleşir. Log retention kısa ise olay tespit edildiğinde gerekli segmentler silinmiş olabilir. Recovery target belirsizse database hatanın içine kadar ilerleyebilir. Bu yüzden PITR runbook teknik backup ayarlarının yanında incident zaman analizi ve validation sorgularını da içermelidir.

Base Backup

Base backup recovery'nin başlangıç state'ini sağlar. Hedef zamandan önceki ve log zinciriyle uyumlu bir backup seçilmelidir. En yeni backup target'tan sonra alınmışsa kullanılamayabilir. Backup'ın başarılı job kaydı olması yeterli değildir, checksum ve restore test ile gerçekten okunabildiği doğrulanmalıdır. Backup metadata'sı başlangıç LSN, WAL range veya binlog position gibi log koordinatlarını içermelidir. Bu bilgiler recovery automation'ın doğru log segmentlerini seçmesine yardımcı olur.

Transaction Logs

Transaction logs base backup sonrasında database'e uygulanan değişiklik geçmişini sağlar. SQL Server log backup, PostgreSQL archived WAL ve MySQL binlog bu amaçta farklı mekanizmalarla kullanılır. Gerekli aralıkta tek bir segmentin kaybolması recovery target'a ulaşmayı engelleyebilir. Log archive production dışında ve mümkünse farklı failure domain'de tutulmalıdır. Retention süresi incident detection süresinden kısa olmamalıdır. Log integrity düzenli restore drill ile doğrulanmalıdır.

Recovery Target

Recovery target database'in replay işlemini nerede durduracağını belirler. Timestamp, LSN, transaction ID, binlog position, GTID veya named restore point gibi seçenekler teknolojiye göre değişir. Hatalı transaction'ın tam commit sınırını belirlemek ideal yaklaşımdır. Timestamp kolay görünür ancak timezone ve aynı saniyedeki transaction yoğunluğu risk yaratabilir. Deployment öncesi oluşturulan named restore point veya kaydedilmiş log sequence değeri çoğu zaman daha güvenilir hedef sağlar. Recovery target belirsiz olduğunda production cutover yapılmadan önce farklı target'larla birden fazla recovery denemesi gerekebilir.

Log Replay

Log replay base backup'ı hedef state'e doğru ilerletir. İşlem sırası bozulmamalı ve bütün segmentler eksiksiz bulunmalıdır. Replay throughput database boyutundan bağımsız olarak RTO üzerinde büyük etki yapabilir. Yüksek günlük WAL veya binlog üretimi çok eski base backup'tan recovery süresini uzatır. Restore drill sırasında yalnızca backup copy süresini değil log replay hızını da ölçmek gerekir. Recovery target'a ulaşıldığında database hemen production'a açılmamalı ve önce read-only doğrulama yapılmalıdır.

PITR Adım Adım Nasıl Çalışır?

PITR operasyonu teknik olarak basit görünse de incident baskısı altında yanlış target seçimi ciddi ikinci hasar oluşturabilir. Süreç olay zamanını belirlemekle başlar. Ardından olaydan önceki uygun base backup seçilir ve production'dan ayrı recovery instance üzerinde restore edilir. Loglar hedef transaction'a kadar replay edilir. Database hedefe ulaştığında kritik tablolar ve business veriler doğrulanır. Son aşamada full cutover mı yoksa selective recovery mi yapılacağına karar verilir. Önceden yazılmış runbook ve otomatik validation sorguları bu süreci hem hızlandırır hem insan hatasını önemli ölçüde azaltır.

1. Olay Zamanını Belirleme

İlk görev yanlış değişikliğin ne zaman başladığını mümkün olduğunca kesin belirlemektir. Application log, audit log, deployment kaydı ve database log koordinatları birlikte incelenebilir. Kullanıcının “yaklaşık saat 14:00” ifadesi doğrudan recovery target olarak kullanılmamalıdır. Server timezone, application timezone ve log timestamp formatı doğrulanmalıdır. Mümkünse hatalı transaction'ın LSN, GTID veya binlog position gibi deterministik koordinatı bulunmalıdır. Olay penceresi netleşmeden restore başlatmak daha sonra aynı işlemi birkaç kez tekrar etmenize neden olabilir.

2. Olaydan Önceki Base Backup'ı Seçme

Seçilen backup recovery target'tan önceki tutarlı state'i kapsamalıdır. Çok eski backup daha fazla log replay gerektirerek RTO'yu uzatabilir. Çok yeni backup ise hatalı transaction'ı zaten içinde taşıyor olabilir. Backup catalog target ile uyumlu en uygun restore noktasını otomatik önerebilir. Dosyanın checksum ve manifest doğrulaması yapılmalıdır. Recovery runbook seçim kararını kaydetmeli, böylece farklı operatörler aynı olay için farklı backup kullanıp sonuçları karşılaştırmak zorunda kalmamalıdır.

3. Base Backup'ı Restore Etme

Restore mümkün olduğunda production üzerine doğrudan yapılmamalıdır. Ayrı recovery instance mevcut production state'ini korur ve yanlış restore hedefinin blast radius değerini azaltır. Recovery storage'ın performansı production'dan çok düşükse ölçülen RTO gerçeği yansıtmayabilir. Restore sırasında backup checksum veya manifest validation çalıştırılmalıdır. Database henüz application trafiğine açılmamalıdır. Base restore tamamlandığında log replay için gerekli başlangıç sequence ve archive erişimi tekrar doğrulanmalıdır.

4. Transaction Log'ları Replay Etme

Base backup sonrasında oluşan loglar doğru sırayla uygulanır. SQL Server'da ilgili log backup zinciri, PostgreSQL'de archived WAL, MySQL'de binary log event'leri kullanılır. Replay sırasında missing segment veya checksum hatası oluşursa işlem güvenli biçimde durdurulmalıdır. Hedefe yaklaşırken yanlış transaction'ın içine geçmemek için recovery target ayarı tekrar kontrol edilmelidir. Replay rate ölçülerek beklenen bitiş süresi hesaplanabilir. Çok yavaş replay varsa RTO hedefini karşılamak için gelecekte base backup sıklığı veya recovery infrastructure kapasitesi yeniden tasarlanmalıdır.

5. Hatalı Transaction'dan Önce Durma

PITR'ın en kritik noktası yanlış işlemin uygulanmasından hemen önce recovery'yi durdurmaktır. Timestamp kullanılıyorsa inclusive veya exclusive davranış teknolojiye göre doğrulanmalıdır. Aynı saniyede doğru ve yanlış transaction'lar bulunabilir. Named restore point, LSN veya event position daha kesin sınır sağlayabilir. Recovery durduğunda database hemen writable production hâline getirilmemelidir. Önce hatalı transaction'ın gerçekten bulunmadığı ve ondan önceki son doğru işlemin mevcut olduğu doğrulanmalıdır.

6. Recovery Sonucunu Doğrulama

Database'in başarılı biçimde açılması recovery'nin doğru olduğu anlamına gelmez. Kritik tablolarda row count, toplam değer, business invariant ve referential integrity kontrolleri yapılmalıdır. Olayın etkilediği örnek kayıtlar business owner ile doğrulanmalıdır. Hatalı transaction'ın ürettiği özel değer veya row'ların bulunmadığı test edilmelidir. Son doğru transaction'ın bulunduğu da ayrıca kontrol edilmelidir. Bu doğrulamalar önceden SQL script hâlinde hazırlanırsa incident sırasında manuel sorgu hatası riski azalır.

7. Promotion / Cutover

Validation tamamlandıktan sonra recovery instance'ın nasıl production'a alınacağına karar verilir. Tam database cutover gerekiyorsa application writes kontrollü biçimde durdurulmalı ve DNS, connection string veya cluster role değişikliği planlanmalıdır. Selective recovery yapılacaksa yalnızca gerekli kayıtlar production'a taşınır. Cutover sonrasında monitoring yoğunlaştırılmalı ve replication, backup ile archive süreçlerinin yeni primary üzerinde devam ettiği doğrulanmalıdır. Eski production instance forensic amaçla bir süre izole tutulabilir. Yanlışlıkla iki writable primary oluşmasını engellemek kritik güvenlik adımıdır.

Recovery Target Nasıl Belirlenir?

Recovery target seçimi PITR operasyonunun en riskli kararlarından biridir. Timestamp kolay anlaşılır olduğu için sık kullanılır ancak her zaman en kesin yöntem değildir. LSN, transaction ID, binlog position, GTID ve named restore point daha deterministik seçenekler sunabilir. Seçimin güvenilirliği yalnızca koordinat türüne değil olay sırasında bu bilginin gerçekten kaydedilmiş olmasına bağlıdır. Deployment pipeline veya kritik batch job başlangıcında recovery marker üretmek bu nedenle çok değerlidir. Amaç incident anında “yaklaşık zaman” tahmini yapmak yerine bilinen son doğru transaction sınırını teknik kayıtlarla gösterebilmektir.

Timestamp ile Recovery

Timestamp tabanlı recovery belirli tarih ve saate kadar log replay yapılmasını sağlar. Operatörler için okunması kolaydır ve incident kayıtları çoğu zaman zaman bilgisi içerir. Ancak timezone, clock drift ve aynı timestamp aralığında bulunan çok sayıda transaction hedefi belirsizleştirebilir. Database'in recovery target inclusive davranışı ayrıca kontrol edilmelidir. Timestamp kullanılıyorsa önce ayrı recovery instance üzerinde sonuç doğrulanmalı ve production cutover yalnızca doğru transaction sınırı kesinleştiğinde yapılmalıdır.

LSN ile Recovery

LSN log içindeki kesin konumu ifade ettiği için timestamp'e göre daha deterministik olabilir. SQL Server ve PostgreSQL bu tür sequence koordinatlarını recovery ve replication süreçlerinde kullanır. Hatalı transaction'ın LSN değeri biliniyorsa recovery hemen öncesinde durdurulabilir. Ancak olay anında LSN kaydı yoksa sonradan log analizinden doğru değeri bulmak zaman alabilir. Deployment ve migration sistemlerinin database LSN bilgisini otomatik kaydetmesi bu nedenle recovery hazırlığını önemli ölçüde iyileştirir.

Transaction ID ile Recovery

Transaction ID doğrudan belirli işlemle ilişki kurma avantajı sağlar. Ancak transaction ID'nin atanma sırası ile commit sırası her database'de aynı olmayabilir. PostgreSQL gibi sistemlerde bu ayrım recovery target yorumunu etkileyebilir. Araç desteği ve olayın transaction ID'sini doğru tespit etme kolaylığı teknolojiye göre değişir. Bu nedenle transaction ID tabanlı recovery kullanmadan önce database'in resmi recovery semantics davranışı test ortamında doğrulanmalıdır.

Binlog Position ile Recovery

MySQL binary log position belirli event'in dosya içindeki kesin sınırını verir. mysqlbinlog üzerinden replay yapılırken stop-position kullanmak timestamp'e göre daha kontrollü sonuç sağlayabilir. File name ile position birlikte kaydedilmelidir. Log rotate olduğunda aynı position değeri başka file içinde bulunabilir. Backup veya deployment metadata'sına current binlog file ve position eklemek incident sırasında hedef belirleme süresini ciddi biçimde azaltır.

GTID ile Recovery

GTID transaction'ı topology içinde benzersiz tanımladığı için replication ve recovery süreçlerinde güçlü referans sağlar. Belirli transaction'ın uygulanıp uygulanmadığını GTID setleri üzerinden takip etmek mümkündür. Bununla birlikte GTID history yanlışlıkla reset edilirse önemli metadata kaybolabilir. Binary log retention ile GTID state birlikte korunmalıdır. Recovery runbook GTID'nin hangi noktada kaydedileceğini ve restore sonrasında duplicate transaction uygulanmasını nasıl engelleyeceğini açık biçimde tanımlamalıdır.

Named Restore Point

Named restore point insan tarafından anlamlandırılmış belirli database recovery koordinatını oluşturur. PostgreSQL pg_create_restore_point gibi mekanizmalar deployment öncesinde kullanılabilir. “release_2026_08_24_before_migration” benzeri isim, yalnızca timestamp'e göre incident sırasında çok daha anlaşılır hedef sunar. İsim convention merkezi olmalı ve deployment ID ile eşleştirilmelidir. Restore point oluşturmak backup yerine geçmez. İlgili noktayı kapsayan base backup ve WAL archive bulunmadığında isim tek başına recovery sağlayamaz.

Hangi Yöntem Daha Güvenlidir?

En güvenli yöntem olay için en kesin ve doğrulanabilir transaction sınırını veren yöntemdir. Önceden kaydedilmiş LSN, GTID, binlog position veya named restore point çoğu zaman tahmini timestamp'ten daha güçlüdür. Bununla birlikte teknoloji desteği ve operasyon pratiği seçimde belirleyicidir. Recovery ekibinin hiç kullanmadığı karmaşık bir koordinat yöntemi incident anında hata riskini artırabilir. Bu nedenle standart target yöntemi runbook içinde seçilmeli, düzenli restore drill ile ekip tarafından uygulanmalı ve timestamp yalnızca gerekli durumlarda ek referans olarak kullanılmalıdır.

Timestamp Tabanlı PITR'ın Riskleri

Timestamp tabanlı PITR pratik görünse de özellikle yüksek transaction hacminde beklenmedik riskler taşır. Uygulama logu ile database server farklı timezone kullanabilir. Yaz ve kış saati değişiklikleri yerel zaman kayıtlarını belirsiz hâle getirebilir. Aynı saniye içinde yüzlerce transaction commit etmiş olabilir. Dağıtık sistemlerde server clock farkları olay sırasını yorumlamayı zorlaştırabilir. Bu nedenle zaman bilgisi incident analizinde güçlü bir başlangıç noktası olsa da mümkün olduğunda database'e özgü LSN, GTID veya position değeriyle desteklenmelidir. Recovery validation olmadan timestamp üzerinden production'a doğrudan geçmek gereksiz risk oluşturur.

Time Zone Hataları

Application UTC loglarken database local timezone kullanıyor olabilir. Incident kaydındaki 14:10 değerinin hangi timezone'a ait olduğu belirtilmemişse recovery bir saat veya daha fazla sapabilir. Bu hata database'i yanlış transaction state'ine getirebilir. Kurumsal logging standardı bütün timestamp değerlerini UTC veya açık offset ile kaydetmelidir. İnsan arayüzünde yerel saat gösterilebilir ancak recovery metadata mutlak zaman formatını korumalıdır. Drill sırasında farklı timezone kayıtlarının nasıl karşılaştırıldığı test edilmelidir.

Yaz/Kış Saati

Daylight saving kullanan bölgelerde belirli yerel saat yılda iki kez oluşabilir veya bazı saat aralıkları hiç yaşanmayabilir. Timestamp offset içermiyorsa hangi gerçek ana karşılık geldiği belirsizleşir. Türkiye sabit saat uygulasa bile global cloud ve çok bölgeli sistemlerde farklı timezone'lar devrede olabilir. Recovery target kayıtlarının ISO 8601 offset veya UTC biçiminde tutulması bu riski azaltır. Operatörün olay sırasında manuel saat dönüşümü yapması yerine tooling target zamanını otomatik normalize etmelidir.

Aynı Saniyedeki Birden Fazla Transaction

Yüksek trafikli database bir saniyede binlerce transaction commit edebilir. Hatalı işlem ile doğru işlemler aynı saniye içinde gerçekleşmişse saniye çözünürlüğündeki target yeterince kesin değildir. Microsecond desteği bulunsa bile application timestamp ile database commit sırası tam eşleşmeyebilir. Log position veya LSN bu durumda daha güvenilir sınır sağlar. Recovery instance üzerinde son doğru ve ilk hatalı transaction kontrolü yapılmadan promote işlemi gerçekleştirilmemelidir.

Server Clock Farkları

Application, database ve audit sistemlerinin saatleri küçük miktarda farklı olabilir. NTP problemi veya yanlış timezone ayarı bu farkı daha da büyütebilir. Incident timeline oluşturulurken farklı kaynaklardaki timestamp'ler doğrudan aynı kabul edilmemelidir. Her sistemin clock source ve offset bilgisi göz önünde bulundurulmalıdır. Merkezi time synchronization monitoring bu sorunu azaltır. Recovery target mümkünse database log koordinatıyla doğrulanmalıdır.

LSN/GTID Kullanmanın Avantajı

LSN ve GTID doğrudan database transaction veya log sırasıyla ilişkilidir. Saat senkronizasyon probleminden etkilenmezler. Hatalı transaction'ın hemen önceki veya sonraki sınırını daha kesin ifade edebilirler. Bununla birlikte incident anında bu koordinatların nereden bulunacağı bilinmelidir. Deployment ve kritik batch süreçlerinde değerleri otomatik kaydetmek recovery hazırlığını güçlendirir. Zaman bilgisi kullanıcı iletişimi için korunurken teknik recovery target sequence bilgisiyle yönetilebilir.

Recovery Target'a Ulaşınca Hemen Production'a Geçilmeli mi?

Hayır, recovery target'a ulaşılması production cutover için tek başına yeterli değildir. Database teknik olarak açılabilir ancak yanlış transaction target'a dahil olmuş olabilir. Son doğru transaction'ın bulunması ve hatalı transaction'ın bulunmaması açık sorgularla doğrulanmalıdır. Kritik tablolar read-only modda incelenmeli ve business owner örnek kayıtları kontrol etmelidir. Pause-before-promote yaklaşımı recovery ekibine geri dönüşü zor bir adım atmadan önce son kontrol fırsatı verir. Incident baskısı altında bu aşamayı atlamak ikinci bir veri kaybı olayına neden olabilir.

Pause-Before-Promote Yaklaşımı

Pause-before-promote recovery engine hedef noktaya ulaştığında database'i doğrudan normal write trafiğine açmak yerine bekletmeyi ifade eder. Bu süre boyunca DBA ve uygulama ekibi state'i inceleyebilir. Hedef yanlışsa recovery yeniden farklı noktaya çalıştırılabilir. Promotion yapıldıktan sonra yeni timeline veya yeni write geçmişi oluşabileceği için geri dönüş daha fazla plan gerektirir. Runbook bu bekleme aşamasını zorunlu gate hâline getirirse operasyon baskısı altında bile validation atlanmaz.

Read-Only Validation

Recovered database mümkünse doğrulama sırasında read-only tutulmalıdır. Böylece test sorguları yeni transaction üretmez ve state değişmeden incelenebilir. Business kullanıcıları yalnızca gerekli veri örneklerini kontrol edebilir. Application testleri write gerektiriyorsa recovery instance'ın ayrı clone'u kullanılabilir. Read-only validation sonucu incident kaydına eklenmeli ve promotion kararı açık onayla verilmelidir. Bu yöntem recovery target'ın kanıtlanabilir biçimde doğrulanmasını sağlar.

Kritik Tabloların Kontrolü

Her database tablosunu manuel olarak incelemek gerçekçi değildir. Bunun yerine recovery runbook kritik business tablolarını ve doğrulama sorgularını önceden belirlemelidir. Order count, ledger balance, inventory quantity veya tenant row count gibi invariant'lar kullanılabilir. Referential integrity ve duplicate kayıt kontrolleri de eklenebilir. Olayın etki alanına göre özel sorgular hazırlanmalıdır. Kontrol sonucu beklenen değerlerle uyuşmuyorsa production promotion yapılmamalıdır.

Olaydan Önceki Son Doğru Transaction'ın Kontrolü

Yalnızca hatalı işlemin bulunmadığını kontrol etmek yeterli değildir. Recovery target fazla erken seçildiyse son doğru işlemler de kaybolmuş olabilir. Bu nedenle bilinen son geçerli transaction recovery instance içinde doğrulanmalıdır. Transaction ID, order number veya audit kaydı bu kontrol için kullanılabilir. Böylece target'ın hatanın hemen öncesine kadar ilerlediği kanıtlanır. Bu doğrulama RPO'nun gereksiz biçimde kötüleşmesini önler.

Hatalı Transaction'ın Bulunmadığının Doğrulanması

Incident'a neden olan transaction'ın ürettiği değişiklikler recovered database içinde yer almamalıdır. Yanlış DELETE ise silinen örnek kayıtların mevcut olduğu doğrulanabilir. Yanlış UPDATE ise problemli değerin uygulanmadığı kontrol edilir. Migration hatası varsa schema version ve dönüştürülmüş row sonuçları incelenir. Bu test doğrudan olay için özel olmalıdır. Genel database health check tek başına doğru target seçildiğini kanıtlamaz.

In-Place Restore mu Ayrı Recovery Instance mı?

Çoğu veri kurtarma olayında ayrı recovery instance daha güvenli başlangıç noktasıdır. Production üzerine doğrudan restore yapmak mevcut state'i kaybetme ve forensic kanıtları yok etme riski taşır. Ayrı instance olay öncesi state'i yeniden oluştururken production verisini karşılaştırma için korur. Selective recovery gerekiyorsa eski ve yeni state arasındaki fark çıkarılabilir. Full cutover kararı daha sonra verilebilir. Storage ve compute maliyeti geçici olarak artsa da incident sırasında geri dönüş seçeneklerinin açık kalması çoğu kurumsal sistemde bu maliyetten daha değerlidir.

Mevcut Production State'ini Korumak

Production database hatalı data içeriyor olsa bile olay sonrasında gerçekleşen doğru transaction'ları da barındırabilir. Doğrudan eski backup restore etmek bu geçerli veriyi silebilir. Mevcut instance'ı korumak selective reconciliation için kaynak sağlar. Ayrıca incident forensic analizi sırasında hangi değişikliklerin gerçekten oluştuğu incelenebilir. Production state snapshot veya immutable copy ile güvence altına alındıktan sonra recovery işlemi ayrı ortamda başlatılmalıdır.

Forensic Analiz

Olayın kök nedenini anlamak için mevcut database state'i önemli kanıt olabilir. Yanlış transaction'ın hangi row'ları etkilediği, hangi kullanıcı veya deployment tarafından oluşturulduğu analiz edilebilir. Production üzerine doğrudan restore yapmak bu bilgilerin bir kısmını ortadan kaldırabilir. Audit, application ve transaction log kayıtları birlikte korunmalıdır. Forensic analiz tamamlanmadan log retention veya cleanup job'larının önemli kayıtları silmesi engellenmelidir.

Ayrı Recovery Sunucusu

Ayrı recovery server production workload'dan bağımsız restore ve replay yapılmasını sağlar. CPU, storage ve network kapasitesi RTO hedefini karşılayacak seviyede olmalıdır. Çok düşük özellikli “acil durum VM'i” gerçek felakette log replay'i saatlerce uzatabilir. Recovery environment IaC ile önceden tanımlanırsa gerektiğinde hızlı kurulabilir. Network erişimi sınırlı olmalı ve application'ın yanlışlıkla bu instance'a write göndermesi engellenmelidir.

Selective Data Recovery

Selective recovery yalnızca kaybedilen veya bozulmuş kayıtların eski state'ten alınmasını hedefler. Yanlış DELETE olayında recovery instance'tan silinen row'lar çıkarılabilir. Tam database rollback yapılmadığı için olaydan sonra oluşan doğru transaction'lar korunur. Bununla birlikte foreign key, sequence ve ilişkili aggregate değerleri kontrol edilmelidir. Recovery script idempotent olmalı ve production'a uygulanmadan önce dry-run sonucu business owner tarafından doğrulanmalıdır.

Blast Radius'i Azaltmak

Ayrı recovery instance üzerinde yapılan hata production kullanıcılarını doğrudan etkilemez. Yanlış target seçilirse instance silinip recovery tekrar çalıştırılabilir. Production üzerine yapılan restore hatasında ise geri dönüş çok daha zor olabilir. Bu nedenle izolasyon incident management içinde blast radius değerini küçültür. Access policy de recovery environment'ı sınırlamalı ve yalnızca recovery ekibine gerekli yetkileri vermelidir.

Bütün Database'i Geri Almadan Veri Kurtarılabilir mi?

Evet, birçok logical corruption olayında bütün production database'i geriye almak zorunlu değildir. PITR ayrı bir instance üzerinde hata öncesi state'i yeniden oluşturabilir. Ardından tek tablo, tek tenant, tek müşteri veya belirli kayıt grubu çıkarılarak production'a taşınabilir. Bu yaklaşım yanlış transaction sonrasında oluşan doğru işlemlerin kaybını önler. Ancak selective recovery business ilişkilerini anlamayı gerektirir. Tek row'u geri getirmek bağlı order, payment veya audit kayıtlarını tutarsız bırakabilir. Bu yüzden reconciliation script veri modelini bilen application ve DBA ekipleri tarafından birlikte hazırlanmalıdır.

Selective Recovery

Selective recovery eski state'ten yalnızca gerekli veri alt kümesini çıkarmayı amaçlar. Recovery instance read-only kaynak olarak kullanılabilir. Etkilenen primary key listesi incident analizinden elde edilir. Sonra production state ile karşılaştırma yapılarak hangi kayıtların ekleneceği veya düzeltileceği belirlenir. Bu yöntem full rollback'ten daha kontrollüdür ancak veri bağımlılıklarını doğru yönetmek gerekir. Uygulama seviyesindeki business invariant'lar işlem sonrasında yeniden doğrulanmalıdır.

Tek Tablo Kurtarma

Yanlış DROP veya DELETE yalnızca bir tabloyu etkilediyse recovery instance'tan tablo verisi export edilebilir. Fakat table schema ile production schema migration sonrasında değişmiş olabilir. Column mapping ve constraint davranışı kontrol edilmelidir. Büyük tabloda yalnızca etkilenen partition veya row aralığını taşımak daha verimli olabilir. Production import işlemi transaction içinde ve geri alınabilir planla yapılmalıdır. Restore öncesi yeni backup almak ek güvenlik sağlar.

Tek Müşteri/Kayıt Kurtarma

Multi-tenant sistemlerde incident tek tenant ile sınırlı olabilir. Bütün database'i eski zamana döndürmek diğer müşterileri gereksiz yere etkiler. Tenant ID üzerinden recovery instance'tan ilgili kayıtlar çıkarılabilir. Bağlı tabloların tamamı aynı tenant kapsamıyla incelenmelidir. Multi-tenant veri modelinde recovery sınırlarının nasıl tasarlanabileceğini daha geniş açıdan değerlendirmek için https://www.diyarbakiryazilim.com.tr/posts/coklu-kiracili-multi-tenant-veritabani-tasarim-modelleri içeriği de yararlı bir tamamlayıcıdır.

Recovery Instance'dan Production'a Veri Taşıma

Data transfer doğrudan copy-paste mantığıyla yapılmamalıdır. Kaynak ve hedef schema sürümleri karşılaştırılmalıdır. Upsert veya insert sırasında mevcut yeni kayıtların üzerine yanlışlıkla yazılmaması gerekir. Script önce staging tabloya veri yükleyip fark raporu oluşturabilir. Business owner ve DBA onayından sonra transaction içinde production değişikliği uygulanabilir. İşlem sonrası row count, checksum ve business validation yeniden çalıştırılmalıdır.

Reconciliation

Reconciliation recovery state ile mevcut production state arasındaki farkı business kurallarına göre uzlaştırır. Hatalı transaction sonrasında gerçekleşen geçerli işlemler korunur. Aynı kaydın hem recovery state'inde hem yeni production state'inde farklı biçimde değişmiş olması conflict oluşturabilir. Otomatik “eski değeri yaz” kuralı bu durumda doğru olmayabilir. Conflict listesi business owner'a sunulmalı ve karar kaydedilmelidir. Bu süreç veri kurtarmayı teknik restore işleminden gerçek iş doğruluğuna taşıyan kritik aşamadır.

PITR Sonrasında Doğru Transaction'lar Nasıl Korunur?

PITR ile geçmiş noktaya dönmek hatalı transaction'ı ortadan kaldırırken ondan sonra gerçekleşen doğru işlemleri de kaldırabilir. Bu nedenle olayın başlangıcı ile fark edilme anı arasındaki business activity analiz edilmelidir. Tam database rollback yalnızca bu aralıktaki veri kaybı kabul edilebilir olduğunda uygun olabilir. Çoğu online sistemde selective restore daha güvenli sonuç verir. Recovery instance hata öncesi state'i, mevcut production ise olay sonrası doğru ve yanlış değişikliklerin karışımını temsil eder. Reconciliation bu iki kaynağı kullanarak yalnızca bozuk veriyi düzeltmeyi hedefler.

Hatalı İşlemden Sonraki Geçerli Transaction'lar

Hata saat 10:00'da gerçekleşmiş ancak 10:30'da fark edilmiş olabilir. Bu yarım saatte yüzlerce geçerli sipariş, ödeme veya kullanıcı güncellemesi gerçekleşebilir. Production'ı 09:59'a almak bu doğru işlemleri de siler. Incident analysis bu transaction hacmini ve business önemini ölçmelidir. Verinin seçici biçimde kurtarılması mümkünse full rollback yerine tercih edilebilir. İş birimi kabulü olmadan doğru transaction'ların kaybına yol açacak geniş restore yapılmamalıdır.

Tam Database Rollback'ın Veri Kaybı Riski

Full rollback basit görünür çünkü tek restore işlemiyle hata öncesi state elde edilir. Ancak recovery target sonrasında oluşan bütün değişiklikler kaybolur. Bu kayıp RPO hedefinin teknik olarak kabul ettiği süreden çok daha büyük olabilir. Hata erken fark edilmemişse saatlerce business transaction etkilenebilir. Full rollback kararı teknik ekip tarafından tek başına verilmemelidir. Business owner hangi veri kaybının kabul edilebilir olduğunu açık biçimde değerlendirmelidir.

Selective Restore

Selective restore yalnızca bozulmuş veri setini eski state'ten geri getirir. Bu yaklaşım olaydan sonraki geçerli işlemleri korur. Uygulama data modelinin ilişkilerini iyi anlamayı gerektirir. Parent ve child kayıtlar, aggregate değerler ve event-driven downstream sistemler birlikte değerlendirilmelidir. Restore sonrası gerekiyorsa event replay veya cache invalidation yapılmalıdır. Teknik düzeltme başka sistemlerdeki yanlış state'i otomatik olarak geri almayabilir.

Transaction Reconciliation

Transaction reconciliation eski ve yeni state arasındaki değişiklikleri tek tek sınıflandırır. Hatalı transaction'ın etkileri geri alınırken geçerli transaction'lar korunur. Aynı kayda iki farklı doğru değişiklik uygulanmışsa conflict çözüm kuralı gerekir. Script sonucu production'a yazılmadan önce human-readable rapor üretmelidir. Büyük olaylarda önce küçük sample üzerinde doğrulama yapılmalıdır. İşlem tamamlandıktan sonra audit kaydı hangi row'un neden değiştirildiğini göstermelidir.

Business Owner Onayı

Database teknik olarak hangi state'in mümkün olduğunu gösterebilir ancak hangi state'in iş açısından doğru olduğunu her zaman bilemez. Ödeme iptali, teslimat durumu veya muhasebe kaydı gibi bilgiler business kararına bağlı olabilir. Bu nedenle recovery validation içine business owner eklenmelidir. Onay sadece mesajla verilmemeli ve incident kaydında hangi veri setinin doğrulandığı belirtilmelidir. Böylece recovery sonrası anlaşmazlıklarda karar süreci izlenebilir kalır.

PostgreSQL'de WAL ve PITR

PostgreSQL PITR, fiziksel base backup ile archived WAL segmentlerinin birlikte kullanılmasına dayanır. WAL archiving etkinleştirildiğinde tamamlanan WAL segmentleri production dışındaki güvenli archive konumuna gönderilebilir. Recovery sırasında restore_command gerekli segmentleri getirir ve PostgreSQL belirlenen target'a kadar WAL replay gerçekleştirir. Target timestamp, LSN, transaction ID veya named restore point olabilir. Promotion sonrasında yeni timeline oluştuğu için restore planı timeline history dosyalarını da kapsamalıdır. Base backup, archive sürekliliği ve düzenli restore drill olmadan yalnızca archive_mode ayarını açmak gerçek recoverability garantisi sağlamaz.

WAL Nedir?

WAL PostgreSQL'in Write-Ahead Log mekanizmasıdır. Değişikliklerin data page'e yazılmasından önce gerekli recovery kaydı WAL içinde oluşturulur. Segmentler pg_wal altında tutulur ve normal işletimde PostgreSQL tarafından yönetilir. Continuous archiving etkin olduğunda tamamlanan segmentler ayrıca archive storage'a gönderilebilir. WAL replication, crash recovery ve PITR gibi birden fazla görevin temelidir. Bu nedenle pg_wal dizinindeki dosyaları manuel silmek disk alanı açma yöntemi olarak kullanılmamalıdır.

WAL Archiving

WAL archiving tamamlanan segmentlerin ayrı repository'ye kopyalanmasını sağlar. archive_mode ile birlikte archive_command veya desteklenen archive library mekanizması kullanılabilir. Archive komutu yalnızca gerçekten başarılı olduğunda success dönmelidir. Başarısız segmentlerin atlanması log chain gap oluşturabilir. Archive repository production sunucusuyla aynı failure domain'de olmamalıdır. Monitoring last archived WAL, failure count ve archive lag değerlerini takip etmelidir.

Base Backup

PostgreSQL PITR için base backup fiziksel başlangıç state'ini sağlar. pg_basebackup veya özel backup araçları bu amaçla kullanılabilir. Backup'ın ilgili WAL başlangıç ve bitiş bilgileri korunmalıdır. Çok eski base backup daha fazla WAL replay gerektirerek RTO'yu uzatır. Backup frequency bu nedenle yalnızca storage maliyetine göre değil replay kapasitesi ve hedef recovery süresine göre ayarlanmalıdır. Random restore drill base backup'ın gerçekten kullanılabilir olduğunu doğrulamalıdır.

restore_command

restore_command recovery sırasında PostgreSQL'in ihtiyaç duyduğu archived WAL dosyasını nasıl alacağını tanımlar. Komut istenen segment mevcutsa doğru dosyayı hedef path'e getirmeli, mevcut değilse failure sonucu dönmelidir. Object storage kullanan sistemlerde wrapper script veya backup tool bu işi gerçekleştirebilir. Credential yönetimi recovery environment içinde önceden test edilmelidir. Archive erişimi ancak incident sırasında ilk kez denenirse IAM veya network hataları RTO'yu beklenmedik biçimde uzatabilir.

recovery_target_time

recovery_target_time PostgreSQL recovery işlemini belirli timestamp'e kadar ilerletmek için kullanılır. Olay zamanı kesin biliniyorsa kullanışlıdır. Timezone ve inclusive davranışı açık biçimde doğrulanmalıdır. Yüksek transaction yoğunluğunda timestamp hedefi LSN veya named restore point kadar kesin olmayabilir. Recovery instance target'a ulaştığında doğrudan production'a geçirilmemelidir. Hatalı transaction'ın bulunmadığı validation sorgularıyla kanıtlanmalıdır.

recovery_target_lsn

recovery_target_lsn WAL replay'in belirli LSN değerine kadar ilerlemesini sağlar. LSN doğrudan WAL koordinatı olduğu için timestamp belirsizliğini azaltabilir. Deployment öncesi LSN otomatik kaydedilirse incident recovery hızlı hedeflenebilir. Değerin inclusive davranışı ayrıca configuration ile ilişkilidir. Yanlış LSN seçimi beklenen transaction'ı dahil edebilir veya son doğru transaction'ı dışarıda bırakabilir. Bu nedenle target result her zaman read-only doğrulanmalıdır.

recovery_target_xid

recovery_target_xid belirli transaction ID sınırına göre recovery hedeflemeye imkân sağlar. PostgreSQL transaction ID'lerin başlangıç sırası ile commit sırası aynı olmak zorunda olmadığı için bu yöntem dikkatle kullanılmalıdır. Incident sırasında doğru XID'yi bulmaya yarayan tooling kısıtlı olabilir. Named restore point veya LSN operasyon ekipleri için çoğu senaryoda daha anlaşılır olabilir. Yine de özel transaction tracking yapılan sistemlerde XID faydalı bir koordinat sunabilir. Kullanım öncesi staging ortamında davranış test edilmelidir.

Named Restore Point

PostgreSQL named restore point belirli WAL konumuna anlamlı isim atamayı sağlar. Büyük schema migration veya kritik release öncesinde recovery marker oluşturmak için uygundur. İsim deployment ID veya release version ile ilişkilendirilebilir. Incident sırasında operatör target time tahmini yapmak yerine doğrudan bilinen marker'a recovery yapabilir. Restore point backup değildir ve gerekli WAL segmentlerinin archive içinde bulunması yine zorunludur. Naming standard aynı adı tekrar kullanma veya yanlış environment hedefleme riskini azaltmalıdır.

Recovery Timeline

PostgreSQL recovery ve promotion sonrasında yeni timeline oluşturabilir. Bu mekanizma eski WAL history ile yeni write geçmişinin birbirinden ayrılmasını sağlar. Birden fazla recovery denemesi veya failover olduğunda doğru timeline seçimi önem kazanır. Timeline history dosyalarının archive repository içinde korunması gerekir. Eski primary'nin yanlışlıkla cluster'a tekrar writable olarak katılması split-brain riski oluşturabilir. Recovery runbook promotion sonrasında replication topology'nin nasıl yeniden kurulacağını açık biçimde tanımlamalıdır.

PostgreSQL Timeline Nedir?

Timeline PostgreSQL WAL geçmişinin farklı dallarını ayırt etmesini sağlayan mekanizmadır. PITR yapılıp geçmiş noktadan yeni write işlemleri başlatıldığında eski geleceğin üzerine yazmak yerine yeni timeline oluşturulur. Böylece aynı base geçmişinden farklı recovery dalları teknik olarak korunabilir. Failover ve yeniden recovery senaryolarında timeline bilgisi doğru WAL zincirini seçmek için önemlidir. Timeline history dosyaları bu ilişkileri açıklar. Operasyon ekibi timeline kavramını anlamıyorsa promotion sonrasında eski primary'nin yanlış şekilde tekrar devreye girmesi veya yanlış archive dalından recovery yapılması gibi ciddi sorunlar yaşayabilir.

Promotion Sonrasında Yeni Timeline

Recovery veya standby promotion sonrasında PostgreSQL yeni timeline oluşturabilir. Yeni transaction'lar bu timeline üzerinde ilerler. Önceki timeline'daki gelecekteki WAL kayıtları artık yeni primary'nin geçerli history'si değildir. Bu ayrım aynı WAL sequence konumlarının farklı history dallarında karışmasını önler. Monitoring ve backup araçları yeni timeline'ı otomatik takip etmelidir. Promotion sonrası archive test edilmezse yeni WAL segmentleri beklenen repository'ye gitmeyebilir.

Timeline History

Timeline history dosyası yeni timeline'ın hangi önceki timeline'dan ve hangi noktada ayrıldığını belirtir. Recovery sırasında PostgreSQL doğru geçmiş zincirini seçmek için bu bilgiyi kullanabilir. Archive repository yalnızca WAL segmentlerini değil history dosyalarını da korumalıdır. Manuel cleanup script'leri .history dosyalarını gereksiz görüp silmemelidir. Çok sayıda failover yaşanan sistemlerde timeline zinciri karmaşıklaşabileceği için backup tooling'in bu bilgileri otomatik yönetmesi önemlidir.

Eski Primary'nin Tekrar Bağlanması Riski

Failover sonrasında eski primary kendi eski timeline'ında write history'ye sahip olabilir. Onu doğrudan yeniden primary veya replica olarak açmak split-brain ve data divergence riski oluşturur. Eski node'un yeni primary history'sine güvenli biçimde yeniden senkronize edilmesi gerekir. pg_rewind veya yeniden base backup gibi yöntemler duruma göre kullanılabilir. Otomatik orchestration bu süreci yönetse bile runbook hangi node'un authoritative olduğunu açıkça belirlemelidir. Network partition sona erdiğinde iki writable primary'nin aynı anda erişilebilir kalması engellenmelidir.

PITR Sonrası WAL Archive Sürekliliği

PITR tamamlandıktan sonra veri koruma süreci yeniden başlamalıdır. Yeni timeline üzerindeki WAL segmentleri archive repository'ye başarılı biçimde gönderilmelidir. Eski timeline retention yeni recovery ihtiyacına göre korunabilir. Archive monitoring yeni primary ve timeline bilgisiyle güncellenmelidir. Promotion sonrası ilk backup alınması bazı recovery stratejilerinde gelecekteki restore süresini azaltır. Incident kapatılmadan önce yeni recovery chain için gerçek test planlanmalıdır.

MySQL'de Transaction Log ve Veri Kurtarma

MySQL recovery mimarisini anlamak için InnoDB redo, undo ve binary log rollerini ayırmak gerekir. Redo log crash recovery için önemlidir. Undo log transaction rollback ve MVCC amaçlarına hizmet eder. Binary log ise database değişiklik event'lerini tutar ve replication ile point-in-time recovery süreçlerinde temel kaynaktır. Full backup restore edildikten sonra ilgili binlog event'leri hedef position veya zamana kadar uygulanabilir. GTID transaction history yönetimini kolaylaştırabilir. Kurumsal backup tasarımı bu log türlerini tek bir “MySQL logu” olarak değerlendirmek yerine her birinin ayrı recovery görevini açık biçimde tanımlamalıdır.

InnoDB Redo Log

InnoDB redo log dirty page değişikliklerinin crash sonrasında yeniden uygulanabilmesini sağlar. Commit edilmiş transaction'ın data page'i henüz tablespace'e flush edilmemiş olabilir. Server yeniden açıldığında redo bilgisi kullanılarak database consistent state'e getirilebilir. Redo log PITR için uzun süreli archive geçmişi değildir. Kullanıcı hatasından birkaç gün önceki state'e dönmek için binary log ve base backup gerekir. Bu ayrım MySQL backup tasarımının temelidir.

Undo Log

Undo log eski row version ve transaction rollback işlemlerine yardımcı olur. MVCC sayesinde uzun query geçmişteki tutarlı data görüntüsünü okuyabilir. Uzun transaction purge işlemlerinin ilerlemesini engelleyerek undo alanının büyümesine neden olabilir. Undo log kullanıcıya genel amaçlı backup sağlamaz. Commit edilmiş yanlış DELETE işlemini günler sonra yalnızca undo log'a güvenerek kurtarma planı yapılamaz. PITR için kalıcı backup ve binary log history korunmalıdır.

Binary Log

Binary log database'i değiştiren event'lerin sıralı kaydıdır. Replication source event'leri replica'lara bu log üzerinden iletebilir. Backup sonrasında oluşan event'ler recovery sırasında yeniden uygulanarak database belirli zamana taşınabilir. MySQL 8.4'te binary logging varsayılan olarak etkin olsa bile retention ve archive politikasının ayrıca yapılandırılması gerekir. Logların source üzerinde otomatik purge edilmesi uzun recovery penceresini ortadan kaldırabilir. Uzak ve güvenli archive tasarımı yapılmalıdır.

Binlog Formatları

MySQL binary log farklı formatlarda event kaydedebilir. ROW gerçek row değişikliklerini, STATEMENT SQL statement bilgisini ve MIXED ise koşullara göre iki yaklaşımın birleşimini kullanır. Replication güvenilirliği, log hacmi ve recovery inceleme yöntemi format seçiminden etkilenebilir. Modern sistemlerde ROW yaygın tercih olsa da mevcut application özellikleri değerlendirilmelidir. Format değişikliği yalnızca storage tuning kararı değildir. Recovery tooling ve audit beklentileri de bu seçime göre test edilmelidir.

ROW

ROW format değişen row verisini event seviyesinde kaydeder. Non-deterministic SQL davranışlarının replica üzerinde farklı sonuç üretme riskini azaltır. Yoğun bulk değişikliklerde log hacmi statement formatına göre daha büyük olabilir. Recovery sırasında event'lerin insan tarafından okunması SQL statement kadar basit değildir. mysqlbinlog gerekli event detaylarını incelemeye yardımcı olur. Storage kapasitesi günlük row change hacmine göre planlanmalıdır.

STATEMENT

STATEMENT format database değişikliklerini SQL statement şeklinde loglayabilir. Bazı workload'larda daha küçük log üretimi avantajı sağlayabilir. Ancak non-deterministic veya context-dependent statement'lar replication güvenilirliği açısından sorun oluşturabilir. Recovery sırasında statement'ın yeniden çalıştırılması aynı koşulları gerektirir. Bu format kullanılıyorsa application'ın statement-based replication güvenliği ayrıca değerlendirilmelidir. Yalnızca log boyutunu azaltmak için seçim yapılmamalıdır.

MIXED

MIXED format MySQL'in işlem türüne göre statement veya row logging seçmesini sağlar. Amaç iki yöntemin avantajlarından yararlanmaktır. Bununla birlikte recovery analizinde log içeriğinin iki farklı temsil biçimine sahip olabileceği bilinmelidir. Tooling her iki event türünü desteklemelidir. Format policy production topology üzerinde tutarlı olmalıdır. Değişiklik öncesinde replica ve PITR testleri yapılmalıdır.

Binlog Position

Binlog position belirli file içindeki recovery event sınırını gösterir. Backup alındığı anda file ve position bilgisi metadata'ya kaydedilmelidir. Recovery sırasında log replay bu noktadan başlayabilir. Hatalı transaction bulununca stop-position ile olaydan önce durulabilir. Position değerinin timestamp'ten daha kesin olması yüksek transaction yoğunluğunda avantaj sağlar. Operatörlerin doğru file name ve position çiftini kullanması gerekir.

GTID

GTID transaction'lara global unique identity sağlar. Replica hangi transaction'ları uyguladığını GTID seti üzerinden izleyebilir. Failover ve topology değişikliklerinde position yönetimini kolaylaştırabilir. PITR ve backup süreçlerinde GTID metadata korunmalıdır. GTID history'yi sıfırlayan komutlar ciddi recovery etkisi oluşturabilir. Bakım runbook'larında bu işlemler yüksek riskli olarak işaretlenmelidir.

mysqlbinlog ile PITR

mysqlbinlog binary log dosyalarını incelemek ve seçilen event aralığını uygulamak için kullanılan resmi araçtır. Full backup restore edildikten sonra binlog file'ları doğru sırayla işlenebilir. Start ve stop datetime veya position seçenekleri recovery target belirlemeye yardımcı olur. Birden fazla binlog file uygulanacaksa transaction sırası korunmalıdır. Recovery önce ayrı instance üzerinde yapılmalıdır. Sonuç validation sonrasında production cutover veya selective data transfer kararı verilmelidir.

SQL Server Transaction Log ve Veri Kurtarma

SQL Server transaction log backup ve restore zinciri güçlü PITR yetenekleri sağlar. Bunun için database recovery modelinin uygun olması gerekir. FULL recovery model düzenli log backup ile point-in-time restore desteklerken SIMPLE model transaction log backup desteklemez. BULK_LOGGED belirli bulk işlemler sırasında farklı recovery sınırlamaları oluşturabilir. LSN değerleri full, differential ve log backup zincirini birbirine bağlar. Failure sonrasında mümkünse tail-log backup son kayıtları korumaya yardımcı olur. STOPAT gibi restore seçenekleri belirli zamana recovery yapmayı sağlar. Bunların tamamı düzenli restore test ile doğrulanmalıdır.

LSN

SQL Server LSN log kayıtlarının sırasını belirler. Backup set metadata içinde hangi LSN aralıklarının kapsandığı görülebilir. Restore sırasında full backup'tan sonra differential ve log backup'ların doğru sırası bu koordinatlarla doğrulanır. Eksik log aralığı chain'i kırar. Incident automation msdb backup history veya harici backup catalog üzerinden gerekli sequence'i hızlı belirleyebilir. Metadata'nın sadece production server üzerinde tutulması disaster sırasında erişim sorunu yaratabileceği için merkezi backup inventory faydalıdır.

Virtual Log Files

SQL Server transaction log fiziksel dosya içinde Virtual Log File yapılarına bölünür. Log file sık sık küçük adımlarla büyütülürse çok fazla VLF oluşabilir. Bu durum geçmiş SQL Server sürümleri ve bazı workload'larda recovery ve log management performansını etkileyebilir. Log boyutu planlı biçimde önceden allocate edilmelidir. Sürekli shrink edip yeniden büyütmek VLF yapısını ve IO davranışını olumsuz etkileyebilir. Kapasite problemi root cause çözülerek yönetilmelidir.

Active Log

Active log recovery için hâlâ gerekli olan transaction log bölümünü ifade eder. Uzun transaction, replica gecikmesi veya log backup eksikliği eski log kayıtlarının reusable hâle gelmesini engelleyebilir. Log truncation gerçekleşmediğinde fiziksel file büyümeye devam edebilir. Monitoring log_reuse_wait_desc gibi database'e özgü göstergelerle gerçek nedeni bulmalıdır. Dosyayı shrink etmek aktif log problemini çözmez. Önce truncation'ı engelleyen neden ortadan kaldırılmalıdır.

Recovery Models

SQL Server recovery model database'in transaction log yönetimi ve restore seçeneklerini doğrudan etkiler. SIMPLE, FULL ve BULK_LOGGED modelleri farklı RPO ve operational trade-off sunar. Seçim database kritikliği ve backup stratejisine göre yapılmalıdır. Production database için model değişikliği kontrollü change olarak ele alınmalıdır. Uygulama ekibi yalnızca “FULL daha güvenli” şeklinde karar vermemeli, log backup schedule ve restore testinin gerçekten işletildiğini de doğrulamalıdır.

SIMPLE

SIMPLE recovery model transaction log backup desteklemez. Database engine inactive log alanını yeniden kullanabilir. Bu model düşük kritik veya yeniden üretilebilir veriler için operasyonu sadeleştirebilir. Ancak standart transaction log zinciriyle arbitrary point-in-time recovery yapılamaz. Son full veya differential backup sonrasında oluşan değişiklikler felaket durumunda kaybedilebilir. Business RPO bu sınırlamayı kabul etmiyorsa FULL model değerlendirilmelidir.

FULL

FULL recovery model transaction log backup ve point-in-time restore için temel seçenektir. Log backup düzenli alınmazsa transaction log büyümeye devam edebilir. Sadece recovery model'i FULL yapmak PITR sağlamaz. Backup zinciri başlatılmalı, korunmalı ve restore drill ile test edilmelidir. Düşük RPO isteyen transaction sistemlerinde yaygın seçimdir. Log backup frequency business kayıp toleransından türetilmelidir.

BULK_LOGGED

BULK_LOGGED model belirli bulk operasyonları daha farklı loglama davranışıyla gerçekleştirebilir. Log backup alınabilir ancak bulk-logged operation içeren log backup içinde arbitrary point-in-time recovery sınırlaması oluşabilir. Büyük veri yükleme süreçlerinde log hacmini yönetmek için kullanılabilir. Recovery etkisi anlaşılmadan geçici olarak bu modele geçmek risklidir. Deployment runbook model değişikliğinin başlangıç ve bitiş noktalarını kaydetmelidir. Bulk operasyon sonrası backup zinciri ayrıca doğrulanmalıdır.

Transaction Log Backup

Transaction log backup FULL veya BULK_LOGGED recovery model kullanan database'lerde log kayıtlarını backup zincirine taşır. Düzenli schedule log file içindeki reusable alanın yönetilmesine de yardımcı olur. Backup interval RPO hedefini etkiler. Dosyalar production dışında korunmalı ve checksum ile doğrulanmalıdır. Backup job başarılı olsa bile gerçek restore testi yapılmalıdır. Son successful log backup zamanı monitoring sisteminin temel metriği olmalıdır.

Tail-Log Backup

Tail-log backup son normal log backup sonrasında kalan kayıtları yakalamayı amaçlar. Felaket anında log file hâlâ okunabiliyorsa son transaction'ları koruyabilir. Restore başlamadan önce değerlendirilmelidir. Her senaryoda gerekli değildir. Database target point daha eski backup içinde bulunuyorsa tail-log kullanılmayabilir. Runbook tail alınabilecek koşulları ve alınamayacağı durumlarda kabul edilen RPO'yu açık biçimde tanımlamalıdır.

STOPAT ile PITR

STOPAT SQL Server restore işlemini belirli zamandaki recovery point'e kadar ilerletmek için kullanılabilir. Uygun full backup restore edildikten sonra log backup'lar sırayla uygulanır. Target time'ı kapsayan RESTORE LOG işleminde doğru STOPAT değeri kullanılır. Recovery point hedef zamanda veya öncesindeki son uygun transaction commit sınırına göre belirlenir. Timestamp belirsizliği varsa log analysis ve business kayıtlarıyla sonuç doğrulanmalıdır. Production'a geçmeden önce ayrı recovery instance üzerinde validation yapılması daha güvenlidir.

Transaction Log Truncation Nedir?

Log truncation artık crash veya backup recovery için gerekli olmayan inactive log bölümlerinin yeniden kullanılabilir hâle getirilmesidir. Bu işlem fiziksel log dosyasını otomatik olarak küçültmek anlamına gelmez. SQL Server transaction log file aynı boyutta kalabilir ancak içindeki space yeni log kayıtları için tekrar kullanılabilir. Truncation engellenirse dosya büyümeye devam eder. Sürekli shrink uygulamak root cause'u gizler ve tekrar growth maliyeti oluşturur. Doğru yaklaşım log reuse'u engelleyen aktif transaction, backup gecikmesi veya replication problemi gibi nedeni belirlemek ve capacity planı buna göre düzeltmektir.

Inactive Log Records

Inactive log records artık database recovery veya diğer gerekli süreçler için tutulması gerekmeyen log bölümünü temsil eder. Database bu alanı tekrar kullanabilir. Hangi kaydın inactive sayılacağı active transaction, backup ve replication durumuna bağlıdır. Manuel file silme yapılmamalıdır. Database engine'in truncation mekanizması güvenli kullanım sınırını kendisi yönetir. Monitoring active ve reusable alanı fiziksel file size değerinden ayrı göstermelidir.

Log Space'in Yeniden Kullanılması

Truncation sonrası fiziksel dosya küçülmese bile boşalan VLF veya log alanı yeni transaction'lar için kullanılabilir. Bu normal ve istenen davranıştır. Büyük ama sabit log file her zaman problem değildir. Workload peak döneminde gereken kapasite önceden allocate edilmiş olabilir. Sürekli dosya büyütüp küçültmek storage fragmentation ve latency oluşturabilir. Capacity plan normal peak log kullanımını güvenli payla karşılamalıdır.

Truncation ile Shrink Arasındaki Fark

Truncation log içindeki inactive alanı reusable yapar. Shrink fiziksel file boyutunu küçültmeyi hedefler. Bunlar farklı operasyonlardır. Truncation gerçekleşmiş olsa bile file boyutu değişmeyebilir. Shrink yalnızca kalıcı ve önemli workload değişikliği sonrası nadir durumlarda değerlendirilebilir. Düzenli bakım olarak kullanılması doğru değildir. File tekrar büyüyecekse shrink hiçbir gerçek kapasite avantajı sağlamaz.

Log Dosyasını Sürekli Shrink Etmek Neden Yanlıştır?

Log file workload nedeniyle tekrar büyüyecekse shrink işlemi yalnızca aynı alanı yeniden allocate etmeye zorlar. Growth sırasında transaction latency ve disk fragmentation etkilenebilir. Çok sayıda küçük growth VLF yapısını da olumsuz etkileyebilir. Disk problemi varsa root cause log backup eksikliği veya long-running transaction olabilir. Shrink bu nedeni ortadan kaldırmaz. Sağlıklı çözüm doğru initial size, growth increment ve truncation monitoring kullanmaktır.

Transaction Log Neden Dolar?

Transaction log dolması yalnızca disk kapasitesinin küçük olması nedeniyle gerçekleşmez. Log backup alınmaması, uzun transaction, replication lag ve büyük batch işlemleri log alanının reuse edilmesini engelleyebilir. Availability replica geride kaldığında primary gerekli log kayıtlarını daha uzun süre tutabilir. Disk tamamen dolarsa yeni transaction'lar başarısız olabilir ve production kesintisi yaşanabilir. Bu nedenle disk usage alarmı tek başına yeterli değildir. Log reuse nedeni, generation rate ve estimated time-to-full değerleri birlikte izlenmelidir. Operasyon ekibi sorun çıktığında otomatik shrink yerine gerçek kök nedeni çözmelidir.

Log Backup Alınmaması

SQL Server FULL recovery modelinde log backup alınmazsa log truncation ilerlemeyebilir. File yeni transaction'lar geldikçe büyür. Database'in FULL modelde olması tek başına veri koruması sağlamaz. Backup schedule durmuşsa hem disk hem RPO riski oluşur. Monitoring last successful log backup age değerini doğrudan alarm kriteri yapmalıdır. Job scheduler yeşil görünürken backup repository upload başarısız olmuş olabileceği için uçtan uca başarı doğrulanmalıdır.

Uzun Süreli Transaction

Açık bir transaction eski log kayıtlarının hâlâ gerekli sayılmasına neden olabilir. Saatlerce çalışan batch veya unutulmuş session log truncation'ı engelleyebilir. Log file hızla büyürken DBA yalnızca backup sıklığını artırarak sorunu çözemeyebilir. Oldest active transaction düzenli izlenmelidir. Uygulama transaction kapsamları kısaltılmalıdır. Büyük operasyon business atomicity bozulmadan kontrollü batch'lere ayrılabiliyorsa log baskısı önemli ölçüde azaltılabilir.

Replication Lag

Replica gerekli log değişikliklerini henüz almamış veya uygulamamışsa source bazı kayıtları daha uzun süre tutmak zorunda kalabilir. Network problemi, yavaş replica disk veya ağır query lag oluşturabilir. Replication lag yalnızca read replica freshness problemi değildir, source log retention ve disk kapasitesini de etkileyebilir. Alert hem zaman hem log byte farkını göstermelidir. Lag giderilmeden source log cleanup zorlamak replica'yı yeniden seed etme ihtiyacı doğurabilir.

Availability Replica Lag

SQL Server availability replica geride kaldığında primary log records gönderilene veya hardened duruma gelene kadar gerekli bilgileri tutabilir. Uzun network kesintisi log growth oluşturabilir. Replica health ile primary log usage aynı dashboard üzerinde izlenmelidir. Disk kapasitesi failover veya maintenance sırasında beklenenden uzun lag için güvenlik payı içermelidir. Replica'yı cluster'dan çıkarmak veya yeniden seed etmek yüksek etkili karar olduğu için runbook belirli eşik ve onay süreci tanımlamalıdır.

Büyük Batch İşlemleri

Milyonlarca row'u tek transaction içinde güncellemek yüksek miktarda log üretir. Transaction tamamlanana kadar log alanının önemli bölümü reusable olmayabilir. Disk ihtiyacı işlem başlamadan önce tahmin edilmelidir. Batch'lere bölme mümkünse recovery ve blocking davranışını iyileştirebilir. Ancak her batch arasında commit yapılması business atomicity anlamını değiştirir. Migration tasarımı performans, recovery ve correctness hedeflerini birlikte değerlendirmelidir.

Disk Alanının Bitmesi

Transaction log diskinde boş alan kalmazsa database yeni log kaydı yazamayabilir. Bu durum write transaction'ların durmasına kadar ilerleyebilir. Alarm yalnızca yüzde doluluk değil mevcut generation rate'e göre kalan süreyi de hesaplamalıdır. Emergency disk expansion kısa vadeli çözüm olabilir. Ardından logun neden reusable hâle gelemediği bulunmalıdır. Disk büyütüp root cause'u görmezden gelmek birkaç saat veya gün sonra aynı kesintinin tekrar yaşanmasına neden olabilir.

Uzun Süreli Transaction'lar Recovery'yi Nasıl Etkiler?

Long-running transaction'lar log truncation, file growth ve crash recovery süresi üzerinde belirgin etki oluşturabilir. Transaction başladığı noktadan itibaren belirli log kayıtlarının korunması gerekebilir. Saatlerce açık kalan işlem bu aralığın reusable hâle gelmesini engeller. Crash meydana gelirse tamamlanmamış büyük transaction'ın undo edilmesi recovery süresini uzatabilir. Bu nedenle monitoring yalnızca query duration değil transaction age değerini de izlemelidir. Uygulama connection pool içinde açık transaction unutulması sık görülen problemlerden biridir. Transaction scope mümkün olduğunca kısa tutulmalı ve timeout politikaları business gereksinimiyle uyumlu seçilmelidir.

Log Truncation'ın Engellenmesi

Eski transaction hâlâ açıkken database onun başlangıcından sonraki belirli log kayıtlarını korumak zorunda kalabilir. Bu durum log backup başarıyla alınsa bile space reuse'u sınırlayabilir. DBA monitoring oldest active transaction bilgisini göstermelidir. Transaction'ın hangi application, host veya user tarafından açıldığı bulunmalıdır. Kör biçimde session kill etmek rollback süresi ve business etkisi oluşturabilir. Müdahale öncesi application owner ile koordinasyon gerekir.

Log File Growth

Truncation engellendiğinde yeni transaction'lar için ek log alanı gerekir. File otomatik growth ile büyüyebilir. Çok sık growth storage latency ve filesystem maliyeti oluşturabilir. Disk kapasitesi tükenirse production write kesintisi yaşanabilir. Log generation rate ve oldest transaction age birlikte alarm üretmelidir. Geçici disk artışı yapılırken aynı anda long transaction root cause çözülmelidir.

Crash Recovery Süresinin Artması

Crash sırasında büyük uncommitted transaction varsa database recovery bunun etkilerini temizlemek zorunda kalabilir. Bu işlem RTO'yu beklenenden fazla uzatabilir. Transaction log büyüklüğü tek başına recovery süresini belirlemez ancak işlenecek aktif log miktarı önemlidir. Restore drill içinde büyük transaction failure senaryosu ayrıca test edilebilir. Application ekipleri uzun batch operation'ların outage impact değerini deployment risk değerlendirmesine dahil etmelidir.

Long-Running Transaction Monitoring

Monitoring transaction age için threshold tanımlamalıdır. Threshold her workload için aynı olmak zorunda değildir. OLTP sisteminde birkaç dakikalık transaction şüpheli olabilirken data warehouse batch daha uzun sürebilir. Alarm query text, application name, user ve blocking bilgisiyle zenginleştirilmelidir. Sadece DBA'ya bildirim göndermek yerine ilgili service owner'a routing yapılması çözüm süresini kısaltır. Trend raporu tekrar eden application hatalarını ortaya çıkarabilir.

Transaction Log ve Replication Arasındaki İlişki

Replication mekanizmaları source database üzerindeki değişiklikleri başka sistemlere aktarmak için transaction log veya benzeri değişiklik kayıtlarından yararlanır. SQL Server log shipping ve transactional replication, PostgreSQL streaming replication ve MySQL binary log replication bunun farklı örnekleridir. CDC de çoğu teknolojide log tabanlı değişiklik yakalama yaklaşımını kullanabilir. Replica geride kaldığında source üzerinde log retention ihtiyacı artabilir. Buna rağmen replication backup değildir. Yanlış DELETE veya application bug source üzerinde commit edilirse replica aynı hatayı çok hızlı biçimde uygulayabilir. Bu nedenle recovery için bağımsız backup ve PITR zinciri korunmalıdır.

Log Shipping

Log shipping SQL Server transaction log backup'larını secondary server'a düzenli taşıyıp restore ederek warm standby oluşturabilir. Backup, copy ve restore job'larının üçü de ayrı izlenmelidir. Secondary belirli delay ile tutulursa logical corruption'a karşı sınırlı recovery penceresi sağlayabilir. Ancak log shipping tek başına immutable uzun süreli backup stratejisi değildir. Copy repository ve backup retention ayrıca korunmalıdır. Failover runbook DNS ve application connection değişikliklerini de içermelidir.

Streaming Replication

PostgreSQL streaming replication WAL records'ı primary'den standby'a sürekli iletir. Düşük lag yüksek availability ve read scale için faydalıdır. Aynı zamanda yanlış transaction'lar standby'a da hızla taşınır. Replica WAL archive yerine geçmez. Replication slot kullanılıyorsa geride kalan consumer primary üzerinde WAL birikmesine neden olabilir. Slot lag monitoring disk kapasitesi açısından kritik öneme sahiptir.

Transactional Replication

SQL Server transactional replication committed değişiklikleri subscriber sistemlere aktarabilir. Amaç her zaman disaster recovery değildir ve topology business dağıtım ihtiyacına göre kurulabilir. Source üzerindeki logical hata subscriber'a da taşınabilir. Replication latency düşük olması bu hatayı daha hızlı yayar. Recovery planı subscriber'ın otomatik olarak temiz kopya olduğunu varsaymamalıdır. Backup zinciri bağımsız korunmalıdır.

CDC

Change Data Capture transaction değişikliklerini downstream analytics veya integration sistemlerine aktarmak için kullanılabilir. CDC log retention ve capture job performansından etkilenebilir. Consumer geride kalırsa değişiklik geçmişi kaybolabilir veya source cleanup gecikebilir. CDC event store backup yerine geçmez. Bununla birlikte incident analizinde hangi row'un ne zaman değiştiğini anlamaya yardımcı olabilir. Recovery validation sırasında CDC ve transaction log bilgileri birlikte kullanılabilir.

Replication Lag

Replication lag source ile replica arasındaki veri gecikmesini ifade eder. Düşük lag availability için genellikle iyidir ancak logical corruption da hızla çoğalır. Yüksek lag ise failover sonrası RPO ve source log retention sorunları yaratır. Monitoring hem time lag hem byte veya LSN farkı göstermelidir. Anormal artış network, storage veya uzun transaction kaynaklı olabilir. Alert yalnızca replica ekibine değil database storage riskini yöneten ekibe de ulaşmalıdır.

Replication Backup Yerine Geçer mi?

Hayır, replication backup yerine geçmez. Replica source üzerindeki doğru değişiklikleri kopyaladığı gibi yanlış DELETE, hatalı UPDATE ve bozuk migration işlemlerini de kopyalar. Ransomware veya compromised credential source üzerinden veri değiştirirse aynı değişiklik replica'ya taşınabilir. Backup geçmiş bir state'e dönme imkânı sağlar, replica ise çoğu zaman güncel state'in ikinci kopyasıdır. Yüksek availability ve disaster recovery amaçları birbirine yakın olsa da aynı değildir. Güvenli mimari replica, immutable backup ve point-in-time recovery özelliklerini birbirini tamamlayan ayrı kontroller olarak kullanmalıdır.

Yanlış DELETE'in Replica'ya Aktarılması

Source üzerinde DELETE commit edildiğinde replication bunu normal ve geçerli transaction olarak görür. Replica birkaç saniye içinde aynı kayıtları silebilir. Replica'ya failover yapmak kayıp veriyi geri getirmez. Delayed replica belirli süreli koruma sunabilir ancak delay penceresi sonunda hata yine uygulanacaktır. Asıl uzun vadeli çözüm backup ve PITR zinciridir. Incident detection süresi delayed replica stratejisinden daha uzun olabilecek senaryolar hesaba katılmalıdır.

Application Bug'ının Replica'ya Taşınması

Application bug yanlış data üretmeye devam ederse replica bu transaction'ları eksiksiz kopyalar. Replication'ın sağlıklı olması aslında hatanın başarıyla çoğaltıldığı anlamına gelebilir. Bu nedenle replica consistency ile business correctness aynı şey değildir. Data validation ve anomaly detection application seviyesinde ayrıca yapılmalıdır. PITR geçmişteki doğru state'i bulmaya yardımcı olur. Bug düzeltilmeden recovered database'i yeniden aynı application'a açmak hatanın tekrarlanmasına neden olabilir.

Logical Corruption

Logical corruption fiziksel database dosyaları tamamen sağlıklı olsa bile yanlış business verisinin commit edilmesidir. Replication bununla mücadele etmek için tasarlanmamıştır. Standby da aynı logical state'e gelir. Snapshot ve backup retention geçmiş temiz noktaları korur. PITR daha hassas target seçimi sağlar. Ransomware ve operator error senaryoları bu nedenle logical corruption recovery planında birlikte değerlendirilmelidir.

Replica Promotion ile PITR Arasındaki Fark

Replica promotion mevcut replica'yı yeni primary yaparak availability sağlar. PITR ise geçmişteki belirli state'i yeniden oluşturur. Primary tamamen kaybolmuş ancak replica güncelse promotion en hızlı çözüm olabilir. Yanlış transaction bütün replica'lara uygulanmışsa promotion hiçbir şeyi düzeltmez. O durumda PITR gerekir. Incident runbook failure type'ı önce sınıflandırmalı ve availability problemi ile logical corruption problemini birbirinden ayırmalıdır.

Ransomware Durumunda Transaction Log'lar

Ransomware database verisini uygulama credential üzerinden değiştirebilir veya doğrudan storage dosyalarını şifreleyebilir. İlk durumda kötü transaction'lar replication aracılığıyla replica'lara taşınabilir. İkinci durumda database file ve aynı disk üzerindeki log archive birlikte kullanılamaz hâle gelebilir. Immutable backup ve production'dan izole log archive bu nedenle kritik savunmadır. Recovery ekibi saldırı başlangıç zamanından önceki clean recovery point'i belirlemelidir. Restore ortamı production network'ten izole kurulmalı ve compromised credential'lar rotation edilmeden yeni database normal erişime açılmamalıdır.

Bozuk Değişikliklerin Replica'ya Taşınması

Saldırgan normal database account kullanarak DELETE veya UPDATE yaparsa replication bunları meşru transaction gibi taşır. Replica'nın fiziksel olarak farklı sunucuda olması logical corruption'a karşı koruma sağlamaz. Delayed replica sınırlı zaman avantajı sunabilir. Ancak saldırı fark edilene kadar delay süresi aşılmış olabilir. Immutable backup ve PITR archive daha uzun güvenli history sağlar. Detection ve backup stratejisi birlikte tasarlanmalıdır.

Immutable Backup

Immutable backup belirli retention süresi boyunca silinmesi veya değiştirilmesi engellenen yedek kopyadır. Compromised admin account backup repository'ye erişse bile geçmiş recovery point'lerini korumayı amaçlar. Object lock veya WORM benzeri özellikler kullanılabilir. Retention yanlış belirlenirse geri döndürülemez storage maliyeti veya KVKK saklama problemi oluşturabilir. Recovery drill immutable copy üzerinden de yapılmalıdır. Sadece configuration ekranında özellik açık görmek yeterli değildir.

İzole Log Archive

Transaction log archive production credential'lardan ayrı identity ve account ile korunabilir. Böylece production compromise archive silme yetkisi sağlamaz. Cross-account object storage veya ayrı security boundary bu hedefe yardımcı olur. Archive write identity'nin delete yetkisi olmayabilir. Recovery identity ise yalnızca incident sırasında kontrollü kullanılabilir. Access logları SIEM tarafından izlenmelidir.

Clean Recovery Point

Ransomware recovery'de en zor sorulardan biri saldırının ne zaman başladığını belirlemektir. İlk şüpheli transaction'dan önceki state clean recovery point olarak seçilebilir. Ancak attacker günler önce persistence oluşturmuş ve daha sonra data değiştirmiş olabilir. Database recovery ile application ve identity recovery birlikte planlanmalıdır. Temiz database'i compromised application'a bağlamak yeniden bulaşma riskini artırır. Security incident timeline ile database PITR target koordineli seçilmelidir.

Recovery Ortamının İzolasyonu

Recovery server saldırı devam ederken production network'e doğrudan bağlanmamalıdır. Credential ve secret'lar yeni değerlerle oluşturulmalıdır. Restore edilen database önce forensic ve malware açısından güvenli ortamda doğrulanmalıdır. Application connection yalnızca security incident ekibi onayından sonra açılmalıdır. Backup repository read credential da production host üzerinde kalıcı tutulmamalıdır. Recovery environment kısa ömürlü ve kontrollü identity ile çalışmalıdır.

Transaction Log Retention Süresi Nasıl Belirlenir?

Retention süresi yalnızca kaç günlük disk alanınız olduğuna göre seçilmemelidir. Base backup sıklığı, RPO, incident detection süresi ve recovery hazırlığı için gereken zaman birlikte değerlendirilmelidir. Hatanın ortalama iki gün sonra fark edildiği bir sistemde yalnızca 24 saat log saklamak gerçek PITR ihtiyacını karşılamaz. Ayrıca log üretim hızı storage maliyetini belirler. Güvenlik payı eklenmeli ve uzun tatil dönemleri düşünülmelidir. Kişisel veri içerebilecek logların gereğinden fazla saklanması da uyumluluk riski oluşturabilir. Retention bu nedenle recovery ve veri yönetişimi ekiplerinin ortak kararı olmalıdır.

Base Backup Sıklığı

Sık base backup daha az log replay gerektirebilir. Bu RTO'yu iyileştirir ancak backup storage ve IO maliyetini artırır. Seyrek base backup durumunda daha uzun WAL veya binlog history korunmalıdır. Retention seçimi backup frequency ile doğrudan ilişkilidir. Restore drill farklı yaşlardaki backup'larla yapılmalıdır. Böylece en kötü recovery süresi ölçülebilir.

RPO

RPO veri kaybı toleransını ifade eder. Log archive veya backup sıklığı bu hedefi desteklemelidir. Beş dakikalık RPO isteyen sistemde bir saatlik archive gecikmesi kabul edilemez. Retention ise hedef noktanın ne kadar geriye gidebildiğini belirleyen ayrı boyuttur. Kısa RPO ile uzun recovery window birlikte planlanabilir. Monitoring her ikisini ayrı metrik olarak göstermelidir.

Incident Detection Süresi

Logical corruption her zaman anında fark edilmez. Finans raporu bir hafta sonra yanlış sonucu gösterebilir. Bu durumda üç günlük log retention işe yaramaz. Gerçek incident geçmişi incelenerek ortalama ve kötü durum detection süresi hesaplanmalıdır. Retention bu süreden daha uzun seçilmelidir. Anomaly detection iyileştikçe gerekli recovery window yeniden değerlendirilebilir.

Recovery Hazırlık Süresi

Incident fark edildikten sonra target belirlemek ve recovery environment hazırlamak zaman alır. Log lifecycle rule bu sırada gereken eski segmentleri silmeye devam edebilir. Olay açıldığında ilgili retention otomatik hold mekanizmasıyla dondurulabilir. Backup repository legal veya incident hold desteği sunuyorsa kullanılabilir. Operatörün manuel olarak onlarca lifecycle rule değiştirmesi risklidir. Runbook recovery window'u koruyan adımı erken aşamaya koymalıdır.

Güvenlik Payı

Retention tam hesaplanan minimum değere eşit olmamalıdır. Hafta sonu, tatil, geç alert veya büyük incident gibi durumlar için ek süre gerekir. Güvenlik payı business kritikliğine göre belirlenebilir. Çok büyük log hacminde maliyet yükseliyorsa compression veya daha ucuz archive tier kullanılabilir. Ancak cold storage retrieval süresi RTO'yu etkiler. Maliyet optimizasyonu recoverability hedefini bozmamalıdır.

Günlük WAL/Binlog Üretim Hızı

Retention storage kapasitesi günlük log üretim miktarıyla doğrudan ilişkilidir. Ortalama değer tek başına yeterli değildir, peak günler ölçülmelidir. Release, batch veya kampanya dönemlerinde log volume birkaç kat artabilir. Monitoring daily generated bytes metriğini tutmalıdır. Capacity plan retention gün sayısı ile peak üretimi çarparak güvenlik payı eklemelidir. Compression oranı gerçek log örnekleriyle ölçülmelidir.

Transaction Log Storage Nasıl Boyutlandırılır?

Log storage boyutlandırması günlük ortalama transaction sayısından daha fazla veriye ihtiyaç duyar. Günlük log byte üretimi, peak transaction rate, retention süresi ve archive compression oranı ölçülmelidir. Local active log alanı ile uzun dönem archive storage farklı kapasite modellerine sahiptir. Replication veya archive failure sırasında local retention normalden daha uzun olabilir. Bu nedenle “normal kullanımda yüzde 20 doluyor” bilgisi yeterli değildir. Disk growth alarmı future time-to-full tahmini üretmelidir. Büyük batch veya deployment dönemlerinde beklenen log artışı önceden capacity planına dahil edilmelidir.

Günlük Log Üretim Miktarı

Her database için günde kaç GB WAL, binlog veya transaction log üretildiği ölçülmelidir. Bu değer data growth ile aynı değildir. Küçük bir tablo çok sık UPDATE edildiğinde data size sabit kalırken log volume yüksek olabilir. Daily log metric storage ve network archive kapasitesini belirler. Haftalık ve aylık trend büyüme planlamasına yardımcı olur. Release günleri ayrı etiketlenmelidir.

Peak Transaction Rate

Peak transaction rate log write throughput ihtiyacını belirler. Ortalama düşük olsa bile kampanya veya batch saatlerinde ani spike oluşabilir. Log disk düşük latency ve yeterli write bandwidth sağlamalıdır. Archive upload sistemi de peak generation hızından geri kalmamalıdır. Aksi hâlde local segment backlog büyür. Capacity test production'a benzer peak workload ile yapılmalıdır.

Retention

Archive storage ihtiyacı günlük log üretimi ile retention süresinin birleşimidir. On dört günlük window iki günlük window'a göre yaklaşık yedi kat daha fazla ham log gerektirebilir. Compression ve dedup etkisi teknolojiye göre değişir. Retention policy business requirement üzerinden seçilmelidir. Storage tier maliyeti buna göre optimize edilebilir. Lifecycle rule değişiklikleri review gerektirmelidir.

Compression

Archived log dosyaları uygun araçlarla sıkıştırılabilir. Gerçek compression ratio data karakteristiğine göre değişir. CPU maliyeti ve restore sırasında decompression throughput ölçülmelidir. Çok yüksek compression RTO'yu kötüleştiriyorsa daha dengeli yöntem seçilebilir. Archive tool checksum bilgisini compression sonrasında da doğrulamalıdır. Native backup araçlarının önerdiği formatlar tercih edilmelidir.

Archive Storage

Archive storage local production diskten ayrı tutulmalıdır. Object storage dayanıklılık ve lifecycle yönetimi açısından uygun seçenek olabilir. Cross-region gereksinimi business continuity planına göre değerlendirilmelidir. Çok ucuz cold tier recovery sırasında saatler süren retrieval gecikmesi oluşturabilir. RTO kısa ise yakın dönem loglar daha hızlı tier'da tutulabilir. Daha eski kayıtlar düşük maliyetli storage'a taşınabilir.

Disk Growth Alert'leri

Disk alarmı yalnızca yüzde 80 sabit eşik kullanmamalıdır. Generation rate hızlıysa yüzde 60 seviyesinde bile birkaç dakika içinde alan tükenebilir. Time-to-full metriği daha anlamlı erken uyarı sağlar. Alert log reuse wait veya archive lag bilgisiyle zenginleştirilmelidir. On-call engineer doğrudan muhtemel root cause'u görebilmelidir. Otomatik expansion varsa limit ve maliyet kontrolü de izlenmelidir.

Loglar Production ile Aynı Diskte Saklanmalı mı?

Transaction log ve uzun dönem archive'ı production data ile aynı fiziksel failure domain'de tutmak disaster recovery riskini artırır. Disk veya storage account kaybolduğunda hem database hem recovery kaynağı aynı anda kaybedilebilir. Active transaction log performans nedeniyle ayrı disk üzerinde tutulabilir. Uzun dönem archive ise ayrı sunucu, object storage veya cross-region repository'ye taşınabilir. Immutable storage ransomware riskini azaltır. Tasarımın amacı yalnızca farklı klasör kullanmak değildir, gerçekten bağımsız failure boundary oluşturmaktır. Aynı storage array üzerindeki iki volume bazı arıza türlerinde hâlâ ortak risk taşıyabilir.

Correlated Failure Riski

Data file ve backup aynı disk üzerindeyse disk failure ikisini birden etkiler. Aynı cloud account ve aynı credential ile yönetilen backup da account compromise durumunda benzer risk taşır. Failure domain fiziksel ve idari sınırları birlikte kapsar. Recovery kaynağı production'dan bağımsız korunmalıdır. Architecture review “yedek nerede?” sorusundan sonra “production compromise bu yedeği silebilir mi?” sorusunu da sormalıdır. Cevap evetse izolasyon yetersiz olabilir.

Ayrı Disk

Active transaction log'u ayrı disk üzerinde tutmak IO performansı ve bazı disk failure senaryolarında avantaj sağlayabilir. Sequential log write workload data page random IO'dan ayrılır. Ancak aynı server kaybolursa iki disk de erişilemeyebilir. Bu nedenle ayrı disk off-host backup yerine geçmez. Storage latency ve durability özellikleri log workload'a uygun olmalıdır. Disk performansı commit latency ile doğrudan ilişkilidir.

Ayrı Sunucu

Log backup veya archive dosyalarını ayrı server'a kopyalamak host failure riskini azaltır. Ancak aynı datacenter outage hâlâ iki sistemi etkileyebilir. Backup server production domain credential'larına aşırı bağlı olmamalıdır. Write-only veya restricted transfer account kullanılabilir. Server'ın kendisi de backup ve monitoring kapsamına alınmalıdır. Tek archive server yeni single point of failure oluşturmamalıdır.

Object Storage

Object storage transaction log archive için ölçeklenebilir seçenek sunar. Versioning, lifecycle ve immutability özellikleri recovery tasarımını güçlendirebilir. Upload completion ve checksum doğrulanmalıdır. Credential least privilege ile sınırlandırılmalıdır. Production workload yalnızca yeni archive object yazabiliyor ancak eski object silemiyorsa ransomware etkisi azaltılabilir. Restore download throughput RTO testinde ölçülmelidir.

Cross-Region Archive

Cross-region archive bölgesel disaster senaryosunda recovery kaynağını korur. Network transfer maliyeti ve data residency gereksinimleri değerlendirilmelidir. Replication gecikmesi RPO üzerinde etkili olabilir. Hedef region'da encryption key erişimi ve IAM policy önceden test edilmelidir. Region outage sırasında ilk kez permission problemi keşfetmek RTO'yu uzatır. Düzenli DR drill cross-region log retrieval içermelidir.

Immutable Storage

Immutable storage belirlenen süre boyunca archive object'lerinin değiştirilememesini veya silinememesini sağlar. Ransomware ve kötü niyetli admin riskine karşı güçlü katmandır. Retention süreleri dikkatle planlanmalıdır, çünkü yanlış oluşturulan object gereksiz yere uzun süre tutulabilir. KMS key silme işlemi immutable data'yı fiilen okunamaz hâle getirebileceği için key lifecycle ayrıca korunmalıdır. Restore drill immutable repository'den gerçek log çekmeyi test etmelidir.

Transaction Log Güvenliği

Transaction log yalnızca teknik metadata içeren zararsız dosya olarak görülmemelidir. Log kayıtları değişen row değerlerini veya hassas business bilgisini içerebilir. Backup ve archive kopyaları bu nedenle production data ile benzer confidentiality gereksinimlerine sahip olabilir. Encryption at rest, transport encryption ve least privilege uygulanmalıdır. Backup operator role'ü production query yetkisinden ayrılabilir. Encryption key yönetimi log retention süresiyle uyumlu olmalıdır. Key erken silinirse yedekler restore edilemez. Log access audit edilmeli ve recovery için gerekli credential'lar sıradan application secret'larıyla paylaşılmamalıdır.

Loglarda Hassas Veri Bulunabilir mi?

Evet, transaction log içeriği database teknolojisine göre row değişiklikleri ve dolaylı olarak kişisel veya finansal veri içerebilir. Binary formatta olması verinin güvenli olduğu anlamına gelmez. Yetkili tooling log içeriğini yeniden oluşturabilir. Bu nedenle archive repository hassas veri storage olarak sınıflandırılmalıdır. Test amacıyla production log kopyalarını geliştirici laptoplarına indirmekten kaçınılmalıdır. Recovery drill güvenli ve erişimi sınırlı ortamda yapılmalıdır.

Encryption at Rest

Backup ve archive storage üzerinde encryption at rest kullanılmalıdır. Platform-managed veya customer-managed key seçimi data class ve compliance gereksinimine göre belirlenebilir. Encryption key backup dosyasının yanında plaintext tutulmamalıdır. Restore environment ilgili key'e kontrollü biçimde erişebilmelidir. Key rotation backup restore kabiliyetini bozmamalıdır. Eski archive için gereken key version'lar retention süresince korunmalıdır.

Encryption in Transit

Log backup production'dan archive storage'a taşınırken TLS veya eşdeğer güvenli transport kullanılmalıdır. Internal network otomatik güvenilir kabul edilmemelidir. Backup tool certificate validation yapmalıdır. Cross-region transfer sırasında provider encryption özellikleri doğrulanmalıdır. Legacy FTP veya plaintext network share hassas log archive için uygun değildir. Transfer failure ve retry mekanizması bütünlüğü korumalıdır.

Least Privilege

Backup service account yalnızca ihtiyaç duyduğu database ve repository izinlerine sahip olmalıdır. Application user'ın archive delete yetkisi olmamalıdır. Recovery operator erişimi incident sırasında geçici olarak verilebilir. Human admin ile automated backup identity ayrılmalıdır. Access review düzenli yapılmalıdır. Kullanılmayan eski backup credential'ları revoke edilmelidir.

Backup Operator Yetkileri

Backup operator database backup alma yetkisine sahip olabilir ancak business data üzerinde geniş query yetkisi gerekmeyebilir. Restore işlemi daha yüksek ayrı privilege gerektirebilir. Production üzerine overwrite yetkisi özellikle sınırlandırılmalıdır. Dual approval kritik restore operasyonlarında kullanılabilir. Operator activity audit log'a kaydedilmelidir. Break-glass hesap normal günlük kullanımda kapalı tutulmalıdır.

Key Management

Encrypted archive ancak doğru key mevcutsa recover edilebilir. KMS key retention backup retention'dan kısa olmamalıdır. Key policy recovery region ve account senaryosunu desteklemelidir. Production compromise key deletion yetkisi sağlıyorsa immutable backup bile risk altında olabilir. Key deletion delay ve dual approval kullanılabilir. Restore drill key recovery yolunu da test etmelidir.

KVKK ve Transaction Log'lar

Transaction log ve backup archive içinde kişisel veri bulunma ihtimali KVKK açısından veri güvenliği ve saklama politikası değerlendirmesini gerekli kılar. Binary log formatı veriyi otomatik olarak anonim hâle getirmez. Erişim yalnızca yetkili recovery ve database personeliyle sınırlandırılmalıdır. Retention business continuity ihtiyacıyla orantılı seçilmelidir. Silme taleplerinde backup ve immutable archive etkisi kurumun hukuki ve teknik prosedürleri içinde ayrıca ele alınmalıdır. Audit trail hangi kişinin recovery materyaline eriştiğini göstermelidir. Teknik uygulamalar güncel KVKK yükümlülükleri ve kurum içi hukuk değerlendirmesiyle birlikte yönetilmelidir.

Loglarda Kişisel Veri

Row-level değişiklik içeren transaction log kişisel verinin geçmiş değerlerini taşıyabilir. Ana tabloda kayıt silinse bile archive log içinde belirli süre varlığını sürdürebilir. Data inventory transaction log repository'yi ayrı asset olarak göstermelidir. Yetkisiz analitik veya geliştirme amacıyla log içeriği kullanılmamalıdır. Encryption ve access logging uygulanmalıdır. Retention gerekçesi belgelenmelidir.

Backup ve Archive Kopyaları

Backup ve log archive production verisinin farklı zamandaki kopyalarını içerir. Data classification otomatik olarak bu kopyalara da uygulanmalıdır. Test ortamına restore yapılırken erişim sınırı korunmalıdır. Backup file'ı developer bilgisayarına indirmek gereksiz veri çoğalması oluşturur. Recovery environment kontrollü platformda kurulmalıdır. Süre dolduğunda lifecycle policy güvenli silme sağlamalıdır.

Retention

Retention recovery window ihtiyacı ve hukuki gereksinim temelinde belirlenmelidir. Süresiz log archive saklamak maliyet ve kişisel veri riski oluşturur. Çok kısa retention ise incident recovery kabiliyetini zayıflatır. Data owner, security ve hukuk ekipleri ortak politika geliştirmelidir. İstisnalar süreli olmalıdır. Lifecycle işlemleri audit edilmelidir.

Erişim Kontrolü

Transaction log archive'a erişim normal database kullanıcılarından ayrı tutulmalıdır. Backup operator, security auditor ve recovery administrator rolleri ayrılabilir. Human access MFA ile korunmalıdır. Object storage download işlemleri audit log üretmelidir. Toplu archive export olağan dışı davranış olarak alarm üretebilir. Access review düzenli yapılmalıdır.

Silme Talepleri

Kişisel veri silme talebi backup ve transaction log ortamlarında teknik olarak farklı davranabilir. Immutable veya append-only archive içindeki tek kaydı seçerek değiştirmek recovery bütünlüğünü bozabilir. Bu nedenle kurum backup retention ve doğal expiry yaklaşımını hukuki gereksinimlerle birlikte tanımlamalıdır. Active production data silme işlemi geciktirilmemelidir. Backup'tan restore sonrasında silinmiş verinin yeniden canlanmaması için re-delete veya suppression prosedürü bulunmalıdır. Kesin hukuki uygulama güncel mevzuat ve uzman görüşüyle doğrulanmalıdır.

Audit Trail

Kimlerin backup ve transaction log repository'ye eriştiği izlenmelidir. Restore, download, retention change ve delete gibi kritik operasyonlar kaydedilmelidir. Audit log kendisi de değiştirmeye karşı korunmalıdır. SIEM olağan dışı büyük download veya cross-region erişim için alarm üretebilir. Recovery incident sonunda erişim yetkileri normal seviyeye geri çekilmelidir. Geçici privilege süresi otomatik sona erebilir.

Backup Başarılıysa Veri Kurtarılabilir mi?

Backup job'ın “success” sonucu vermesi gerçek recoverability kanıtı değildir. Job dosyayı oluşturmuş olabilir ancak file bozuk, eksik veya encryption key erişilemez durumda olabilir. Transaction log chain içinde gap bulunabilir. Backup manifest ile beklenen file ve log aralıkları doğrulanmalıdır. En güçlü test başka bir ortamda gerçek restore yapmaktır. Restore sonrası database açılmalı, log replay uygulanmalı ve business validation sorguları çalışmalıdır. Backup programının başarı metriği alınan dosya sayısından çok belirli recovery target'a gerçekten ulaşabilme oranı olmalıdır.

Backup Job Success Ne Kanıtlar?

Job success genellikle backup komutunun belirli anda hata döndürmeden tamamlandığını gösterir. Repository'nin daha sonra dosyayı koruyacağını garanti etmez. File corruption veya lifecycle deletion sonradan gerçekleşebilir. Encryption key gelecekte kaybolabilir. Log chain'in diğer dosyaları eksik olabilir. Bu nedenle success gerekli ancak yetersiz bir sinyaldir.

Checksum Verification

Checksum backup file'ın transfer veya storage sırasında bozulup bozulmadığını tespit etmeye yardımcı olur. Backup oluşturma anında ve restore öncesinde doğrulanabilir. Ancak checksum geçmesi database'in business açısından doğru olduğunu garanti etmez. Ayrıca bütün gerekli log segmentlerinin bulunduğunu da tek başına göstermez. Integrity kontrol restore drill ile birlikte kullanılmalıdır. Checksum failure yüksek öncelikli alarm üretmelidir.

Backup Manifest

Backup manifest hangi file, checksum ve WAL range gibi bilgilerin backup'a ait olduğunu gösterebilir. Automation restore başlamadan önce manifest'i doğrulayabilir. Missing file erken tespit edilir. Metadata merkezi catalog içinde tutulursa incident sırasında doğru backup seçimi kolaylaşır. Manifest de backup repository ile aynı integrity korumasına sahip olmalıdır. Manuel olarak düzenlenmemelidir.

Restore Test

Restore test backup'ın gerçekten kullanılabilir olduğunu kanıtlayan en güçlü operasyonel kontroldür. Ayrı environment'ta database oluşturulur. Gerekli loglar replay edilir. Random recovery target seçilirse chain'in farklı bölümleri zaman içinde test edilir. Sonuç business validation sorgularıyla doğrulanır. Süre ölçülerek RTO hedefiyle karşılaştırılır.

Transaction Log Integrity

Log dosyalarının bulunması yetmez, sequence ve içerik bütünlüğü gereklidir. Missing segment recovery'yi durdurabilir. Checksum ve backup catalog kontrolü gap'i erken bulabilir. Archive upload tamamlanmadan source purge yapılmamalıdır. Restore drill gerçek replay ile en güçlü doğrulamayı sağlar. Integrity metriği monitoring dashboard'da gösterilmelidir.

Gerçek Recoverability

Gerçek recoverability belirli hedefe kabul edilen RTO içinde ulaşabilme yeteneğidir. Backup file sayısı bu kabiliyeti doğrudan ölçmez. Restore, log replay, validation ve cutover aşamalarının tamamı başarılı olmalıdır. Encryption key ve IAM erişimi de sürecin parçasıdır. Drill sonuçları düzenli raporlanmalıdır. Başarısız recovery denemesi production incident yaşanmadan önce öğrenilmiş değerli bir bilgidir.

Restore Drill Nedir?

Restore drill gerçek felaket olmadan recovery sürecini kontrollü biçimde uygulama tatbikatıdır. Ayrı recovery ortamı oluşturulur, base backup restore edilir ve loglar rastgele seçilen hedefe kadar replay edilir. Ardından veri doğrulama sorguları çalıştırılır ve gerektiğinde promotion adımı test edilir. Sürecin her aşamasında geçen süre kaydedilir. Böylece gerçek RTO tahmin yerine ölçümle belirlenir. Restore drill backup sistemindeki eksik IAM, kayıp key, bozuk log veya yetersiz network throughput gibi sorunları production incident öncesinde ortaya çıkarır. Kurumsal transaction log veri kurtarma ve veritabanı yedekleme hizmeti değerlendirilirken de düzenli drill desteği temel kriterlerden biri olmalıdır.

Ayrı Recovery Ortamı

Drill production kullanıcılarını etkilememelidir. İzole network ve ayrı database instance kullanılmalıdır. Backup repository read-only erişimle bağlanabilir. Recovery environment production'a benzer storage ve compute kapasitesinde olursa ölçülen süre daha gerçekçi olur. IaC ile otomatik kurulması tekrar edilebilirliği artırır. Drill bitiminde ortam güvenli biçimde temizlenmelidir.

Base Backup Restore

Rastgele veya policy'ye göre seçilen base backup recovery environment'a restore edilir. Backup transfer süresi ayrıca ölçülür. Checksum ve manifest verification çalıştırılır. Backup bozuksa drill başarısız sayılmalıdır. Başka backup'a geçerek testi yeşil göstermek sorunu gizler. Root cause bulunup düzeltildikten sonra yeniden drill yapılmalıdır.

Log Replay

Base backup sonrasında gerekli transaction logs uygulanır. Replay throughput ve missing segment kontrol edilir. Archive retrieval latency ölçülür. Cold storage'dan log çekiliyorsa bekleme süresi RTO'ya dahil edilir. Hedefe ulaşıldığında database state kaydedilir. Replay error'ları merkezi rapora eklenir.

Random Recovery Target

Her zaman son backup'a restore etmek log zincirinin yalnızca son kısmını test edebilir. Random target farklı gün ve saatlerdeki archive segmentlerinin gerçekten kullanılmasını sağlar. Timestamp ve LSN gibi farklı target yöntemleri dönüşümlü test edilebilir. Özellikle deployment öncesi marker'lar seçilebilir. Böylece gerçek incident'a daha yakın senaryolar denenir. Hedef seçim otomatikleştirilirse test kapsamı zaman içinde genişler.

Veri Doğrulaması

Recovered database yalnızca online olmasıyla başarılı kabul edilmemelidir. Critical table row count, business total ve known transaction kontrolleri çalıştırılmalıdır. Hedef zamandan sonra oluşan transaction'ın bulunmadığı doğrulanabilir. Referential integrity kontrolü eklenebilir. Sonuç baseline ile karşılaştırılır. Validation failure recovery failure olarak raporlanmalıdır.

Promotion Testi

Yüksek availability sistemlerinde recovery instance'ın application tarafından kullanılabilir primary hâline gelmesi ayrıca test edilmelidir. DNS, service discovery ve secret değişiklikleri doğrulanır. Replica topology yeniden kurulabilir. Application smoke test yapılır. Eski primary'nin yanlışlıkla tekrar devreye girmesi engellenir. Cutover süresi toplam RTO'ya dahil edilir.

Süre Ölçümü

Drill her aşamanın başlangıç ve bitiş zamanını kaydetmelidir. Backup copy, restore, log replay, validation ve cutover ayrı ölçülür. Toplam süre business RTO ile karşılaştırılır. En yavaş adım kapasite yatırımı için öncelik gösterir. Sadece son toplam süreye bakmak bottleneck'in nedenini gizler. Trend raporu iyileştirmenin etkisini gösterir.

RTO Transaction Log Recovery İçin Nasıl Hesaplanır?

RTO recovery tamamlanıp business hizmetinin tekrar kullanılabilir olması için kabul edilen maksimum süreyi ifade eder. Transaction log recovery için RTO yalnızca database restore komutunun çalışma süresi değildir. Backup dosyalarının taşınması, logların archive'dan alınması, replay, validation ve application cutover tamamı toplam süreye dahildir. Büyük database'de base restore hızlı olsa bile yüzlerce GB WAL replay RTO'yu aşabilir. Bu nedenle teorik storage throughput hesabı yerine gerçek restore drill sonuçları kullanılmalıdır. Capacity planı en kötü makul incident senaryosuna göre yapılmalıdır.

Backup Copy Süresi

Backup remote object storage'dan recovery region'a taşınacaksa network throughput önemli faktördür. Terabyte ölçeğinde backup birkaç saat sürebilir. Parallel download ve local cache RTO'yu iyileştirebilir. Cold archive tier ek retrieval delay oluşturabilir. Drill bu gerçek storage sınıfını kullanmalıdır. Sadece local test copy ile yapılan ölçüm production felaketini temsil etmez.

Log Transfer Süresi

Archived WAL veya binlog segmentleri recovery ortamına alınmalıdır. Çok sayıda küçük file transfer overhead oluşturabilir. Compression network süresini azaltırken CPU maliyetini artırabilir. Cross-region bandwidth sınırı dikkate alınmalıdır. Archive tool prefetch yapabiliyorsa replay ile transfer paralel ilerleyebilir. Ölçüm gerçek repository üzerinden yapılmalıdır.

WAL/Binlog Replay Süresi

Replay süresi base backup yaşı ve log üretim hacmiyle büyür. High write workload saatlerce log üretmiş olabilir. Recovery storage write throughput yeterli değilse replay yavaşlar. CPU ve single-thread limitleri database teknolojisine göre etkili olabilir. Daha sık base backup RTO'yu azaltabilir. Replay rate drill'de MB/s veya LSN/s gibi metriklerle izlenmelidir.

Validation Süresi

Database açıldıktan sonra business validation zaman alır. Büyük table checksum veya reconciliation sorgusu ağır olabilir. Önceden hazırlanmış hızlı kritik kontrol seti RTO içinde kullanılabilir. Daha ayrıntılı forensic analiz cutover sonrasında devam edebilir. Hangi testlerin promotion için zorunlu olduğu runbook'ta belirtilmelidir. İnsan onay süresi de toplam RTO'dan bağımsız değildir.

Application Cutover Süresi

Database hazır olsa bile application yeni endpoint'e bağlanmadan hizmet geri dönmez. DNS TTL, connection pool ve secret update süresi hesaplanmalıdır. Kubernetes veya service mesh environment'ında endpoint değişimi otomatik olabilir. Legacy application manual config gerektirebilir. Smoke test sonrası write traffic kontrollü açılmalıdır. Bu süre drill sırasında ölçülmelidir.

Gerçek Restore Drill Sonuçlarını Kullanmak

RTO tahmini spreadsheet hesabıyla sınırlı kalmamalıdır. Düzenli drill gerçek infrastructure ve dataset üzerinde ölçüm sağlar. P50 yanında en kötü veya p95 restore süresi takip edilebilir. Database büyüdükçe RTO trendi kötüleşebilir. Yıllar önce ölçülen değer bugünkü data hacmi için geçerli değildir. Capacity ve backup stratejisi drill sonuçlarına göre güncellenmelidir.

RPO Nasıl Hesaplanır?

RPO felaket anında ne kadar veri kaybının kabul edilebilir olduğunu gösterir. Transaction log sistemlerinde gerçek RPO son güvenli ve erişilebilir log noktasına bağlıdır. Log backup schedule beş dakika olsa bile archive upload on dakika gecikiyorsa off-site RPO daha kötü olabilir. Replication lag başka bir sinyaldir ancak replica logical corruption'a karşı backup yerine geçmez. En doğru metrik latest recoverable transaction veya timestamp değeridir. Business ekipleri “sıfır veri kaybı” gibi genel hedef yerine farklı workload'lar için ölçülebilir RPO tanımlamalıdır.

Log Backup Frekansı

SQL Server log backup interval RPO üzerinde doğrudan etkilidir. Backup ne kadar sık alınırsa son güvenli nokta failure'a o kadar yakın olabilir. Çok sık schedule repository ve job management yükünü artırır. Gerçek ihtiyaç business transaction değerine göre belirlenmelidir. Backup completion değil off-host availability zamanı izlenmelidir. Failure öncesi tail-log alınması RPO'yu daha da iyileştirebilir ancak garanti kabul edilmemelidir.

WAL Archive Lag

PostgreSQL WAL segmenti üretildikten sonra archive repository'ye ulaşana kadar zaman geçebilir. Düşük transaction ortamında segment tamamlanması gecikebilir. archive_timeout gibi ayarlar bu davranışı etkileyebilir ancak çok kısa değer storage kullanımını artırabilir. Streaming veya backup tooling daha düşük RPO için değerlendirilebilir. Monitoring source WAL position ile archived position arasındaki farkı ölçmelidir. Archive lag hedef RPO'yu aşıyorsa alarm üretmelidir.

Replication Lag

Replica RPO açısından availability göstergesi sunabilir. Primary kaybolursa replica son replay edilen transaction'a kadar data içerebilir. Ancak logical corruption source'tan replica'ya taşındığı için backup RPO ile replication RPO farklı kavramlardır. Dashboard iki değeri ayrı göstermelidir. Synchronous replication bazı failure senaryolarında veri kaybını azaltabilir ancak latency ve availability trade-off oluşturur. Business gereksinimine göre seçilmelidir.

Son Sağlam Transaction

Gerçek RPO'nun en anlamlı ifadesi felaket anında güvenle geri getirilebilen son transaction'dır. Backup timestamp bu noktayı tam göstermeyebilir. Log archive sequence veya latest restorable time daha doğru bilgi sağlar. Monitoring bunu düzenli hesaplayabilir. Incident sırasında son sağlam transaction business impact analizine çevrilmelidir. Kaç dakika değil kaç sipariş veya ödeme kaybı olduğu da raporlanabilir.

Kabul Edilebilir Veri Kaybı

Her database için aynı RPO gerekli değildir. Finans işlemleri saniyelere yakın hedef isterken yeniden üretilebilir analytics data saatlik kaybı kabul edebilir. Daha düşük RPO daha fazla altyapı ve operasyon maliyeti yaratır. Business owner teknik ekiple birlikte gerçek kayıp etkisini tanımlamalıdır. Hedef resmi service tier'a bağlanmalıdır. Restore drill ölçümü bu hedefin gerçekten karşılanıp karşılanmadığını göstermelidir.

Transaction Log Monitoring

Transaction log monitoring yalnızca disk doluluk yüzdesini izlemekten daha geniş olmalıdır. Log generation rate, disk usage, son başarılı log backup, archive lag, replication lag ve replay rate birlikte değerlendirilmelidir. Missing log segment doğrudan recoverability alarmıdır. Trend analizi normal workload ile anormal batch veya attack davranışını ayırt etmeye yardımcı olur. Metric'ler database technology'ye göre farklı isim taşısa da temel amaç aynı kalır. Sistem ne kadar hızlı log üretiyor, hangi kısmı güvenli archive'a ulaştı ve bugün felaket olursa hangi noktaya ne kadar sürede dönebiliriz sorularına cevap vermelidir.

Log Generation Rate

Log generation rate belirli sürede üretilen transaction log byte miktarını gösterir. Normal baseline üzerinde ani artış large batch, runaway application veya attack belirtisi olabilir. Capacity planning için peak rate önemlidir. Archive bandwidth generation rate'in altında kalırsa backlog büyür. Alert değişim oranını da izleyebilir. Deployment annotation anormal artışın beklenen migration kaynaklı olup olmadığını anlamaya yardımcı olur.

Log Disk Usage

Disk usage aktif log storage'ın ne kadar dolu olduğunu gösterir. Sabit yüzde eşik faydalıdır ancak tek başına yeterli değildir. Growth rate ile time-to-full hesaplanmalıdır. Log reuse wait reason eklenirse operator hızlı root cause bulabilir. Auto-grow event sayısı ayrıca izlenmelidir. Sürekli büyüyen file capacity veya truncation problemine işaret eder.

Last Successful Log Backup

SQL Server FULL recovery model database'lerinde son başarılı log backup zamanı kritik metriktir. Beklenen interval'in iki katına çıkması alarm üretebilir. Backup'ın repository'ye gerçekten ulaştığı doğrulanmalıdır. Job success ama upload failure ayrı durumdur. Dashboard database başına latest backup age göstermelidir. Uzun gecikme hem RPO hem log growth riskidir.

WAL Archive Lag

PostgreSQL archive lag source WAL ile archive repository arasındaki farkı gösterir. Segment count, byte veya time cinsinden ölçülebilir. Archive command failure sayısı ayrıca takip edilmelidir. Local pg_wal büyümesi archive problemine işaret edebilir. RPO hedefini aşan lag yüksek öncelikli alarm olmalıdır. Recovery repository health production SLO'larının parçası hâline getirilmelidir.

Missing Log Segment

Missing segment log chain'i doğrudan kırabilir. Archive inventory sequence continuity kontrolü yapmalıdır. Son segmentin varlığı yeterli değildir. Gap erken bulunursa source üzerinde dosya hâlâ mevcut olabilir ve kurtarılabilir. Geç bulunursa PITR window kalıcı zarar görebilir. Alarm incident olarak ele alınmalıdır.

Replication Lag

Replication lag availability ve log retention üzerinde etkilidir. Time, byte ve transaction farkı birlikte izlenebilir. Ani artış network veya replica storage problemi gösterebilir. Çok uzun lag source disk consumption artırabilir. Failover RPO da kötüleşir. Alert threshold workload kritikliğiyle uyumlu olmalıdır.

Replay Rate

Replay rate recovery ve replica uygulama hızını gösterir. Log generation rate replay rate'ten uzun süre yüksekse lag büyür. Restore drill sırasında replay throughput RTO hesaplamak için kullanılır. Storage veya CPU bottleneck oranı düşürebilir. Database büyüdükçe trend izlenmelidir. Capacity plan production peak log generation üzerinde güvenli replay kapasitesi hedeflemelidir.

Hangi Durumlarda Alarm Üretilmeli?

Alarm eşikleri yalnızca sabit disk yüzdesine göre belirlenmemelidir. Log backup gecikmesi, archive failure, chain gap ve replication lag gerçek recoverability riskleridir. Anormal log üretimi application hatası veya güvenlik olayına işaret edebilir. Restore drill RTO hedefini aşıyorsa production çalışıyor olsa bile veri koruma SLO'su ihlal edilmiştir. Alarm sistemi doğru owner'a yönlendirme yapmalıdır. Backup ekibi, DBA ve application owner sorumlulukları önceden tanımlanmalıdır. Gereksiz alarm gürültüsü gerçek recovery problemlerinin kaçırılmasına neden olacağı için threshold'lar düzenli gözden geçirilmelidir.

Log Disk %80+

Yüzde 80 pratik bir başlangıç eşiği olabilir ancak bütün sistemlerde aynı anlamı taşımaz. Bir TB log diskinde kalan alan büyük olabilirken küçük diskte birkaç dakika içinde dolabilir. Time-to-full metriği daha anlamlıdır. Yüzde 80 alarmına generation rate ve reuse wait bilgisi eklenmelidir. Automatic expansion varsa maksimum limit izlenmelidir. Capacity alert geçici büyütme yanında root cause investigation başlatmalıdır.

Log Backup Gecikmesi

Backup expected schedule'dan belirli süre saptığında alarm üretilmelidir. Threshold RPO hedefinden daha uzun olmamalıdır. On dakikalık RPO için otuz dakikalık alert çok geçtir. Repository upload tamamlanma zamanı ölçülmelidir. Tek database'te problem olabilir. Alarm database name ve son başarılı backup bilgisini içermelidir.

Archive Command Failure

PostgreSQL archive failure WAL segmentinin güvenli repository'ye taşınmadığını gösterebilir. Tek transient failure retry ile düzelebilir. Sürekli failure local pg_wal alanını doldurabilir ve RPO'yu bozar. Alert consecutive failure ve oldest pending segment bilgisi taşımalıdır. Object storage credential expiration sık görülen nedenlerden biridir. IAM rotation restore ve archive testleriyle birlikte yapılmalıdır.

Log Chain Gap

Gap tespit edildiğinde sonraki backup'lar başarılı olsa bile olay kapatılmamalıdır. Eksik aralık recoverability kaybıdır. Source log hâlâ mevcutsa hemen koruma altına alınmalıdır. Değilse business owner etkilenen recovery window hakkında bilgilendirilmelidir. Yeni zincir gerekebilir. Root cause backup system düzeltmesine dönüştürülmelidir.

Replication Lag Artışı

Lag normal baseline'ın belirgin üzerine çıktığında alarm üretilebilir. Sabit saniye eşiği workload'a göre ayarlanmalıdır. Network throughput, replica CPU ve storage latency context olarak eklenebilir. Lag primary log retention'ı etkiliyorsa severity yükseltilmelidir. Planned maintenance annotation false alarmı azaltır. Uzun lag sonrasında replica consistency doğrulanmalıdır.

Anormal Log Üretim Artışı

Normalin birkaç katı log üretimi large UPDATE veya DELETE sinyali olabilir. Deployment sırasında beklenen migration da aynı paterni oluşturabilir. Change record ile correlation yapılmalıdır. Beklenmeyen spike güvenlik ve application ekiplerine bildirilmelidir. Disk time-to-full hızla düşebilir. Query veya transaction source mümkün olduğunca otomatik belirlenmelidir.

Restore Drill RTO İhlali

Drill hedef süreden uzun sürdüyse bu production incident olmadan tespit edilmiş gerçek SLO ihlalidir. Backup “başarılı” olsa bile recovery planı business hedefini karşılamıyor demektir. Bottleneck backup copy, replay veya validation olabilir. Action item owner ve deadline ile açılmalıdır. Bir sonraki drill düzeltmeyi doğrulamalıdır. Sonuç yönetim raporunda görünür olmalıdır.

Database Deployment Öncesi Restore Point Kullanmak

Database migration production için yüksek riskli değişikliklerden biridir. Deployment öncesi backup, recovery marker ve schema version kaydı rollback seçeneklerini güçlendirir. PostgreSQL named restore point gibi özellikler log içinde anlamlı sınır oluşturabilir. SQL Server ve MySQL tarafında ilgili LSN veya binlog position deployment metadata'sına eklenebilir. Hata oluştuğunda yalnızca deployment timestamp tahmini yapmak yerine kesin database koordinatı kullanılabilir. Ancak restore point backup yerine geçmez. Recovery için gerekli base backup ve kesintisiz transaction log history yine bulunmalıdır.

Migration Öncesi Backup

Büyük migration öncesi güncel backup almak recovery başlangıcını yaklaştırır. Böylece hata durumunda uygulanacak log miktarı azalabilir. Backup production workload üzerinde IO etkisi oluşturabileceği için schedule planlanmalıdır. Backup tamamlanmadan migration başlamamalıdır. Checksum ve repository upload doğrulanmalıdır. Kritik migration'da restore test yapılmış son backup zinciri kullanılmalıdır.

Named Restore Point

Named restore point deployment öncesi açık isimli recovery marker sağlar. Release ID ve tarih isim içinde bulunabilir. Incident sırasında hangi marker'ın doğru olduğu change management kaydından bulunur. Duplicate veya manuel isim hatası naming convention ile azaltılır. Marker creation deployment pipeline tarafından otomatik yapılabilir. İlgili WAL veya log retention marker süresini kapsamalıdır.

Deployment Timestamp

Deployment başlangıç ve bitiş zamanı UTC ve timezone offset ile kaydedilmelidir. Bu bilgi application log ve database events ile correlation sağlar. Timestamp tek recovery koordinatı olarak kullanılmasa da önemli incident referansıdır. CI/CD platformu zamanı otomatik üretmelidir. Human tarafından chat mesajına yazılan saat resmi kayıt olmamalıdır. Database marker ile aynı deployment ID altında tutulmalıdır.

Schema Migration Version

Migration tool uygulanan schema version'ı database içinde kaydedebilir. Incident sırasında hangi migration'ın başarıyla tamamlandığı görülür. Version ile Git commit SHA eşleştirilmelidir. Recovery sonrası application'ın database schema compatibility durumu kontrol edilmelidir. Eski data state yeni application code ile uyumsuz olabilir. Cutover planı application rollback'i de içermelidir.

Hatalı Deployment'ta PITR

Migration data'yı geri döndürülemez biçimde bozduysa PITR gerekebilir. Deployment marker hata öncesi hedefi hızlı belirler. Ancak migration sonrasında gerçekleşen doğru kullanıcı transaction'ları full rollback ile kaybolabilir. Olay erken fark edilirse maintenance window içinde tam rollback kabul edilebilir. Geç fark edilirse selective recovery daha uygun olabilir. Business impact analizi teknik restore kararından önce yapılmalıdır.

Transaction Logs ve CI/CD Süreci

CI/CD sistemi application release ile database state arasında güçlü izlenebilirlik sağlayabilir. Deployment ID, Git commit SHA, migration ID ve recovery marker aynı metadata kaydında tutulabilir. Incident sırasında “hangi kod hangi database değişikliğini yaptı?” sorusu hızlı cevaplanır. Pipeline büyük migration öncesi backup veya restore point kontrolünü zorunlu gate hâline getirebilir. Release sonrasında log generation anomaly monitoring otomatik çalışabilir. Bu entegrasyon recovery'yi yalnızca DBA'nın manuel operasyonu olmaktan çıkarır ve yazılım teslim sürecinin doğal güvenlik parçası hâline getirir.

Deployment ID

Her release benzersiz deployment ID taşımalıdır. Database migration ve restore point bu ID ile etiketlenebilir. Monitoring log spike'ını ilgili release'e bağlayabilir. Incident timeline otomatik oluşur. Multi-environment sistemde environment adı metadata içinde bulunmalıdır. Production ve staging marker'larının karışması engellenmelidir.

Commit SHA

Git commit SHA çalışan application code'un kesin sürümünü gösterir. Database değişikliği hangi code revision tarafından tetiklendiği bu değerle takip edilebilir. Application deployment record ve migration log aynı SHA'yı taşımalıdır. Recovery sonrası eski database state'e geçildiğinde uygun application version seçmek kolaylaşır. Container image digest ayrıca kaydedilebilir. Böylece source ile runtime eşleşmesi doğrulanır.

Database Migration ID

Migration ID schema ve data transformation sürümünü gösterir. Framework migration table bu bilgiyi saklayabilir. Pipeline deployment record'a ID eklemelidir. Hatalı migration incident'ında hangi script'in etkilendiği hızlı bulunur. Down migration her zaman güvenli olmadığı için PITR seçeneği ayrıca hazır tutulmalıdır. Migration script production öncesi gerçekçi data hacminde test edilmelidir.

Recovery Marker

Recovery marker deployment öncesindeki kesin database koordinatını ifade eder. PostgreSQL named restore point, LSN veya MySQL binlog position kullanılabilir. Marker CI/CD tarafından otomatik kaydedilebilir. Incident sırasında manual log search süresini azaltır. Marker'ın kendisi recovery kaynağı değildir. Gerekli backup ve log chain'in retention içinde bulunması şarttır.

Incident ile Deployment'ı Eşleştirmek

Monitoring alarmı deployment ID ile correlation yapabilir. Log generation spike release'den hemen sonra başladıysa application change hızlı şüpheli olarak belirlenir. Audit log migration user bilgisini sağlar. Transaction log koordinatı recovery target için kullanılır. Bu metadata tek incident dashboard'da gösterilirse DBA ve developer aynı timeline üzerinde çalışabilir. Mean time to recovery önemli ölçüde azalır.

Managed Cloud Database'lerde PITR

Managed cloud database hizmetleri automated backup ve point-in-time restore işlemlerinin önemli bölümünü platform üzerinden yönetebilir. AWS RDS, Azure SQL ve Google Cloud SQL gibi hizmetler farklı database motorları için PITR seçenekleri sunar. Kullanıcı çoğu zaman ham transaction log dosyasına doğrudan erişmez. Bu operasyonu kolaylaştırır ancak sorumluluğu tamamen ortadan kaldırmaz. Backup retention, latest restorable time, encryption key ve restore region düzenli doğrulanmalıdır. Platformun restore özelliğinin var olması gerçekten test edildiği anlamına gelmez. Kurum kendi verisi ve application cutover süreciyle düzenli managed PITR drill yapmalıdır.

AWS RDS

AWS RDS automated backup ve transaction log mekanizmalarını engine'e göre yöneterek belirlenen retention window içinde point-in-time restore sağlayabilir. Restore işlemi genellikle mevcut instance'ın üzerine yazmak yerine yeni DB instance oluşturur. Bu davranış mevcut production state'ini koruma açısından faydalıdır. Latest restorable time monitoring ile izlenebilir. Backup retention kapatılırsa PITR kabiliyeti etkilenebilir. Customer-managed KMS key kullanılıyorsa recovery account ve region erişimi ayrıca test edilmelidir.

Azure SQL

Azure SQL platform seviyesinde automated backup ve PITR özellikleri sunabilir. Exact retention ve restore seçenekleri hizmet katmanı ve yapılandırmaya göre değişir. Operasyon ekibi portalda özelliğin bulunmasını yeterli kabul etmemelidir. Restore edilmiş database'in firewall, identity ve application connection ayarları ayrıca hazırlanmalıdır. Cross-region business continuity ihtiyacı farklı replication ve backup özellikleri gerektirebilir. Düzenli drill gerçek RTO'yu gösterir.

Google Cloud SQL

Google Cloud SQL desteklenen engine'lerde automated backup ve point-in-time recovery özellikleri sunar. MySQL için binary log, PostgreSQL için WAL tabanlı mekanizmalar platform tarafından yönetilebilir. Kullanıcı çoğu zaman low-level log segmentlerini manuel yönetmez. Retention ve PITR configuration doğru etkinleştirilmelidir. Restore sonrası yeni instance network ve IAM ayarları test edilmelidir. Application cutover toplam RTO'ya dahil edilmelidir.

Provider-Native Automated Backups

Provider-native backup operasyon yükünü azaltır. Scheduling, storage ve log collection'ın önemli kısmı platform tarafından yönetilebilir. Ancak yanlış retention veya backup disable değişikliği veri koruma penceresini ortadan kaldırabilir. Infrastructure policy bu ayarları zorunlu kılabilir. Backup configuration drift monitoring kurulmalıdır. Critical database'lerde restore test otomatik yapılmalıdır.

Managed PITR

Managed PITR operatörün target time seçerek yeni database oluşturmasını kolaylaştırır. Yine de doğru target belirleme, validation ve cutover kurumun sorumluluğundadır. Platform yanlış DELETE'in business anlamını bilemez. Timestamp timezone davranışı dokümantasyondan doğrulanmalıdır. Recovery instance production'dan izole tutulmalıdır. Success metric yalnızca restore job tamamlandı değil application'ın doğru state ile hizmet vermeye başlaması olmalıdır.

Kullanıcının Log Dosyalarına Doğrudan Erişememesi

Managed service ham WAL veya transaction log file erişimini sınırlandırabilir. Bu durum operasyonu sadeleştirir ancak custom forensic ihtiyaçları etkileyebilir. Recovery provider API ve supported target seçenekleriyle yapılır. Runbook low-level file komutları yerine platform workflow'una göre yazılmalıdır. Service export veya audit özellikleri olay analizinde yardımcı olabilir. Vendor documentation değişiklikleri düzenli takip edilmelidir.

Açık Kaynak Transaction Log ve Recovery Ekosistemi

Açık kaynak database ve backup ekosistemi transaction log recovery süreçlerini otomatikleştiren güçlü araçlar sunar. PostgreSQL ve MySQL kendi native mekanizmalarının yanında pgBackRest, Barman, WAL-G ve Percona XtraBackup gibi çözümlerle birlikte kullanılabilir. Doğru araç yalnızca backup alma özelliğine göre seçilmemelidir. Archive verification, retention, parallel restore, encryption ve monitoring özellikleri değerlendirilmelidir. Community-driven runbook ve test senaryoları operasyon kalitesini artırabilir. Buna rağmen her aracın production sürümü, restore davranışı ve failure mode'ları kurumun kendi ortamında doğrulanmalıdır.

PostgreSQL

PostgreSQL native WAL archiving ve physical base backup özellikleri güçlü PITR temeli sağlar. pg_basebackup, restore_command ve recovery target parametreleri kullanılarak manual workflow kurulabilir. Büyük ortamda retention ve archive orchestration için özel backup tool kullanmak operasyonu kolaylaştırabilir. Tool seçilse bile WAL ve timeline kavramlarını anlamak önemlidir. Abstraction arızalandığında DBA underlying mekanizmayı bilmelidir. Test cluster üzerinde native recovery adımları öğrenilmelidir.

MySQL / MariaDB

MySQL ve MariaDB physical veya logical backup seçeneklerinin yanında binary log üzerinden incremental recovery imkânı sunar. Engine ve version farkları dikkate alınmalıdır. MySQL 8.4 davranışı eski sürümlerle birebir aynı olmayabilir. GTID ve binlog retention configuration doğrulanmalıdır. Backup tool restore sonrasında doğru binlog koordinatını sağlamalıdır. Production upgrade sırasında recovery runbook da version değişikliğine göre test edilmelidir.

pgBackRest

pgBackRest PostgreSQL backup, restore, WAL archive ve retention süreçlerini yönetmek için yaygın açık kaynak çözümlerden biridir. Parallel backup ve restore büyük database'lerde RTO açısından avantaj sağlayabilir. Repository encryption ve multiple repository özellikleri değerlendirilebilir. Tool configuration version control altında tutulmalıdır. Restore command ve target options düzenli drill ile test edilmelidir. Sadece backup cron job çalışıyor olması başarı kriteri olmamalıdır.

Barman

Barman PostgreSQL backup ve recovery yönetimi için kullanılan açık kaynak araçlardan biridir. Base backup, WAL archive ve recovery workflow'larını merkezi hâle getirebilir. Birden fazla PostgreSQL server için repository yönetimi sağlar. Network ve disk capacity doğru boyutlandırılmalıdır. Barman server kendisi de kritik recovery dependency olduğundan backup ve HA planı gerektirir. Restore drill doğrudan Barman repository üzerinden yapılmalıdır.

WAL-G

WAL-G PostgreSQL WAL ve backup verisini object storage gibi ortamlara taşıyan araçlardan biridir. Compression ve cloud storage integration büyük ölçekli ortamda faydalı olabilir. Credential yönetimi least privilege ile yapılmalıdır. Backup-fetch ve WAL-fetch işlemleri recovery environment'ta test edilmelidir. Retention komutlarının yanlış kullanımı önemli recovery data kaybı oluşturabilir. Automation üzerinde safety check bulunmalıdır.

Percona XtraBackup

Percona XtraBackup MySQL ve uyumlu InnoDB workload'larında fiziksel hot backup amacıyla kullanılan araçlardan biridir. Büyük database'lerde logical dump'a göre restore avantajı sağlayabilir. Backup sırasında elde edilen binlog position veya GTID metadata PITR için korunmalıdır. Prepare ve restore adımları runbook içinde açık olmalıdır. Tool ve database version compatibility upgrade öncesinde kontrol edilmelidir. Restore test production benzeri data hacminde yapılmalıdır.

Açık Kaynak Restore Otomasyonu

Restore automation tekrar eden adımları standartlaştırır. Base backup seçimi, checksum, log replay ve validation pipeline hâline getirilebilir. Human operator yalnızca recovery target ve promotion onayı verebilir. Automation destructive production action varsayılan olarak yapmamalıdır. Dry-run ve isolated environment default olmalıdır. Script source control ve code review altında tutulmalıdır.

Community-Driven Recovery Runbook'ları

Community runbook'ları farklı failure senaryoları hakkında yararlı fikirler sunar. Ancak doğrudan production'a kopyalanmamalıdır. Database version, storage ve topology farkları adımların davranışını değiştirebilir. Kurum kendi runbook'unu düzenli drill sonucuna göre güncellemelidir. Open source örnekler başlangıç şablonu sağlayabilir. Gerçek recovery authority şirket içi doğrulanmış prosedür olmalıdır.

Kurumsal Transaction Log Recovery Runbook Nasıl Hazırlanır?

Recovery runbook incident sırasında hangi adımın hangi sırayla ve kim tarafından uygulanacağını açıkça belirtmelidir. Genel “backup'tan geri dönün” ifadesi yeterli değildir. Incident tanımı, recovery owner, son sağlam base backup, log chain kontrolü ve recovery target belirleme prosedürü ayrı adımlar olmalıdır. Restore production'dan ayrı instance üzerinde yapılmalı ve validation tamamlanmadan cutover gerçekleştirilmemelidir. Her adımda gerekli command, dashboard ve approval bilgisi bulunmalıdır. Runbook'un gerçek değeri düzenli restore drill sırasında kullanıldığında ortaya çıkar. Kullanılmayan doküman zamanla güncelliğini kaybeder.

Incident Tanımı

İlk adım problemin türünü sınıflandırmaktır. Primary failure, logical corruption, ransomware ve accidental delete farklı recovery yaklaşımı gerektirir. Olay başlangıç zamanı ve etkilenen database listesi kaydedilmelidir. Production writes durdurulacaksa business impact değerlendirilmelidir. Incident commander atanmalıdır. Yanlış problem sınıflandırması gereksiz PITR veya veri kaybı oluşturabilir.

Recovery Owner

Recovery owner teknik restore sürecinden sorumlu kişidir. Bu rol incident commander ile aynı olmak zorunda değildir. DBA command'ları çalıştırırken application ve business ekipleri validation sağlar. Yetki sınırları önceden belirlenmelidir. Birden fazla kişinin aynı anda farklı restore başlatması engellenmelidir. Action log tutulmalıdır.

Son Sağlam Base Backup

Backup catalog olaydan önceki son uygun base backup'ı göstermelidir. Checksum ve manifest durumu doğrulanmalıdır. Target'tan sonra alınmış backup seçilmemelidir. Backup'ın recovery log zinciriyle bağlantısı kontrol edilmelidir. Dosyanın bulunduğu storage ve encryption key erişimi test edilir. Seçim incident kaydına yazılır.

Log Chain Kontrolü

Base backup'tan target'a kadar bütün log segmentleri mevcut olmalıdır. Sequence continuity otomatik script ile kontrol edilebilir. Missing segment varsa source veya replica üzerinde kopya aranabilir. Gap çözülmeden recovery sonucunun eksiksiz olacağı varsayılmamalıdır. Archive checksum doğrulanmalıdır. Chain status incident severity içinde görünür olmalıdır.

Recovery Target

Hatalı transaction'ın kesin sınırı belirlenmelidir. Timestamp, LSN, GTID veya restore point kullanılabilir. Application ve audit log bilgisi karşılaştırılır. Target'ın inclusive davranışı kontrol edilir. Belirsizlik varsa birden fazla recovery denemesi planlanabilir. Karar ve gerekçe incident kaydına eklenir.

Ayrı Recovery Instance

Restore production üzerine yapılmamalıdır. Recovery environment önceden IaC ile tanımlanmış olabilir. Network isolated ve access restricted tutulur. Storage kapasitesi yeterli olmalıdır. Backup ve KMS erişimi test edilir. Instance açıkça recovery etiketi taşır.

Replay

Base backup açıldıktan sonra log replay target'a kadar ilerletilir. Progress ve error kayıtları izlenir. Missing segment durumunda işlem durdurulur. Replay rate RTO karşılaştırmasına eklenir. Target'a ulaşıldığında writes kapalı tutulur. Promotion yapılmaz.

Validation

Critical table sorguları otomatik çalıştırılır. Son doğru transaction ve ilk hatalı transaction kontrol edilir. Business owner sample data'yı doğrular. Referential integrity ve row count incelenir. Sonuç beklenmiyorsa target yeniden değerlendirilir. Validation kanıtları incident ticket'a eklenir.

Cutover

Full cutover veya selective recovery kararı verilir. Application write trafiği kontrollü durdurulur. Endpoint değişikliği yapılır. Smoke test başarıyla tamamlanır. Eski production izole edilir. Backup ve replication yeni primary üzerinde yeniden başlatılır.

Post-Recovery Monitoring

Recovery sonrası normalden yoğun monitoring uygulanmalıdır. Error rate, replication lag ve transaction log generation izlenir. Backup ve archive job'larının yeni instance üzerinde başarılı olduğu doğrulanır. Application data anomaly tekrar oluşuyor mu kontrol edilir. Incident root cause tamamlanmadan monitoring normale döndürülmemelidir. Lessons learned runbook'a eklenir.

İşlem Günlüğü ve Veri Kurtarma İçin Adım Adım Yol Haritası

Kurumsal recovery programı bir gecede kurulmaz. Önce hangi database teknolojilerinin kullanıldığı ve her birinin hangi log mekanizmasına sahip olduğu envanterlenmelidir. Sonra workload bazında RPO ve RTO hedefleri business ekipleriyle belirlenir. Base backup ve log archive sistemi bu hedeflere göre kurulur. Archive production dışına taşınır ve monitoring ile zincir bütünlüğü izlenir. En önemli adım ise restore drill otomasyonudur. Ölçülen gerçek sonuçlara göre backup sıklığı, retention ve infrastructure kapasitesi düzenli biçimde iyileştirilmelidir.

1. Database Teknolojilerine Göre Log Türlerini Envanterleyin

Her production database listelenmelidir. SQL Server recovery model, PostgreSQL WAL archive ve MySQL binlog configuration ayrı kaydedilir. Database owner ve business criticality belirtilir. Replication ve backup tool bilgisi eklenir. Unknown database recovery riski olarak işaretlenir. Inventory otomatik discovery ile güncel tutulmalıdır.

2. İş Yükü Bazında RPO/RTO Belirleyin

Her workload aynı kritik seviyede değildir. Business owner kabul edilebilir veri kaybı ve kesinti süresini tanımlamalıdır. RPO dakika veya saat olarak ölçülür. RTO restore ve cutover'ın tamamını kapsar. Hedefler teknik kapasiteyle karşılaştırılır. Maliyet ve risk dengesi yönetim tarafından onaylanır.

3. Base/Full Backup Stratejisini Kurun

Backup sıklığı RTO ve storage ihtiyacına göre belirlenir. Full backup çok seyrekse log replay uzayabilir. Backup repository production'dan ayrılmalıdır. Encryption ve checksum etkin olmalıdır. Catalog metadata tutulmalıdır. Düzenli restore testi zorunlu olmalıdır.

4. WAL/Binlog/Transaction Log Archiving Etkinleştirin

Database teknolojisine uygun incremental log koruması kurulmalıdır. SQL Server log backup, PostgreSQL WAL archive ve MySQL binary log retention ayrı süreçlerdir. Archive completion doğrulanmalıdır. Source cleanup yalnızca güvenli kopya sonrası yapılmalıdır. Upload failure alarm üretmelidir. Recovery target'a kadar continuity izlenmelidir.

5. Log Retention Süresini Belirleyin

Retention incident detection süresinden uzun olmalıdır. Business recovery window hedefi dikkate alınır. Günlük log volume storage maliyetini belirler. Security buffer eklenir. Kişisel veri saklama gereksinimleri değerlendirilir. Lifecycle policy code review altında tutulur.

6. Archive'ı Production Dışında Saklayın

Archive aynı host veya aynı disk üzerinde bırakılmamalıdır. Object storage veya ayrı account kullanılabilir. Immutable storage yüksek riskli sistemlerde değerlendirilir. Encryption key ayrı yönetilir. Production identity delete yetkisi taşımayabilir. Cross-region recovery test edilmelidir.

7. Log Chain Monitoring Kurun

Sequence continuity otomatik kontrol edilmelidir. Last backup ve archive lag ölçülmelidir. Missing segment kritik alarmdır. Dashboard latest recoverable point göstermelidir. File existence checksum ile desteklenmelidir. Monitoring restore drill sonucuyla doğrulanmalıdır.

8. Recovery Target Prosedürünü Tanımlayın

Standart target yöntemi database teknolojisine göre seçilmelidir. Timestamp yanında LSN, GTID veya named marker kullanımı tanımlanabilir. Deployment pipeline recovery koordinatını kaydetmelidir. Timezone standardı UTC olmalıdır. Inclusive davranış dokümante edilmelidir. Örnek incident üzerinden test edilmelidir.

9. Ayrı Recovery Environment Oluşturun

Recovery infrastructure önceden IaC ile tanımlanmalıdır. Network isolation ve IAM hazır olmalıdır. KMS erişimi test edilmelidir. Compute kapasitesi RTO hedefini karşılamalıdır. Environment gerektiğinde hızlı oluşturulabilmelidir. Production data erişimi kontrollü tutulmalıdır.

10. PITR Runbook Yazın

Runbook command ve ekran adımlarını açıkça göstermelidir. Recovery owner ve approval rolleri belirtilir. Backup seçimi, replay ve validation ayrı aşamalardır. Production overwrite varsayılan olmamalıdır. Tail-log gibi teknolojiye özel seçenekler eklenir. Doküman version control altında tutulmalıdır.

11. Recovery Validation Sorgularını Hazırlayın

Critical business data için önceden test sorguları yazılmalıdır. Row count ve toplam değer kontrolleri bulunabilir. Known transaction doğrulanabilir. Referential integrity test edilir. Query'ler read-only olmalıdır. Sonuç formatı incident kaydına eklenebilir olmalıdır.

12. Restore Drill Otomasyonu Kurun

Backup seçimi ve recovery environment provisioning otomatikleştirilebilir. Random target kullanılır. Log replay ve validation script çalıştırılır. Sonuç raporu üretilir. Failure durumunda alarm açılır. Production'a otomatik promotion yapılmamalıdır.

13. Gerçek RTO ve RPO'yu Ölçün

RTO restore drill üzerinden ölçülmelidir. RPO latest recoverable transaction veya time üzerinden hesaplanmalıdır. Planlanan hedef ile gerçek sonuç karşılaştırılır. Trend dashboard oluşturulur. Büyüyen database etkisi izlenir. İhlal durumunda capacity veya backup strategy değiştirilir.

14. Drill Sonuçlarına Göre Backup Sıklığını Optimize Edin

Replay çok uzunsa daha sık base backup düşünülebilir. Backup overhead yüksekse farklı incremental strateji değerlendirilebilir. Log archive bandwidth artırılabilir. Cold storage retrieval RTO'yu aşıyorsa tier değiştirilebilir. Kararlar gerçek ölçüme dayanmalıdır. Her değişiklik sonraki drill'de doğrulanmalıdır.

15. Runbook'u Düzenli Güncelleyin

Database version ve cloud service davranışı zamanla değişir. Eski command veya UI adımı incident sırasında zaman kaybettirebilir. Her drill sonrası öğrenilen bilgi dokümana eklenmelidir. Owner değişiklikleri güncellenmelidir. Link ve credential erişim yolları kontrol edilmelidir. En azından belirlenen periyotta formal review yapılmalıdır.

En Sık Yapılan Transaction Log ve Recovery Hataları

Transaction log recovery hatalarının çoğu teknoloji eksikliğinden değil yanlış varsayımdan kaynaklanır. Replication'ı backup sanmak, restore testi yapmamak ve log chain'i izlememek en yaygın örneklerdendir. Log dosyasını sürekli shrink etmek kapasite problemini çözmez. Timestamp'i tahmin ederek doğrudan production restore yapmak ciddi veri kaybı yaratabilir. Managed database hizmetinde PITR özelliğinin bulunması onun kurumunuz adına düzenli test edildiği anlamına gelmez. Sağlıklı süreç gerçek restore, validation ve ölçüm üzerine kurulmalıdır. Hataları runbook ve automation seviyesinde önlemek kişisel deneyime güvenmekten daha sürdürülebilir sonuç verir.

Transaction Log'u Audit Log Sanmak

Transaction log recovery içindir. Audit log kullanıcı ve erişim izlenebilirliği sağlar. İki kayıt farklı amaçlara sahiptir. Transaction log'dan tam business audit beklemek yanlıştır. Audit log'u PITR kaynağı olarak kullanmak da mümkün değildir. Her ikisi ayrı retention ve security policy gerektirir.

Replication'ı Backup Sanmak

Replica yanlış transaction'ı da kopyalar. Logical corruption saniyeler içinde bütün replica'lara yayılabilir. Replica historical state sağlamaz. Backup ve PITR geçmiş recovery noktası sunar. HA ve recovery iki ayrı tasarım hedefidir. Her ikisi birlikte kullanılmalıdır.

Backup Alıp Restore Testi Yapmamak

Backup job success gerçek recoverability kanıtlamaz. File bozuk olabilir. Key erişilemeyebilir. Log chain eksik olabilir. Düzenli restore drill bu sorunları ortaya çıkarır. Test yapılmayan backup güvenilir kabul edilmemelidir.

Log Chain'i İzlememek

Tek missing segment bütün PITR hedefini bozabilir. Son backup başarılı görünse bile geçmişte gap bulunabilir. Sequence continuity otomatik kontrol edilmelidir. Missing file erken bulunmalıdır. Source üzerinde kopya hâlâ mevcutken kurtarma şansı daha yüksektir. Gap kritik incident kabul edilmelidir.

Logları Erken Silmek

Kısa retention storage maliyetini düşürür ancak recovery window'u küçültür. Olay geç fark edildiğinde gerekli WAL veya binlog bulunmayabilir. Detection süresi retention hesabına dahil edilmelidir. Lifecycle rule yanlışlıkla geniş delete yapmamalıdır. Immutable veya backup repository korunmalıdır. Silme policy review gerektirmelidir.

Transaction Log Dosyasını Sürekli Shrink Etmek

Shrink root cause çözmez. File workload nedeniyle yeniden büyür. Growth transaction latency oluşturabilir. VLF yapısı olumsuz etkilenebilir. Doğru file size peak ihtiyaca göre belirlenmelidir. Truncation engeli ayrıca çözülmelidir.

Timestamp ile Recovery Target'ı Tahmin Etmek

Yaklaşık zamanla PITR yapmak son doğru transaction'ları kaybedebilir veya hatalı işlemi dahil edebilir. Application timestamp database commit anıyla aynı değildir. LSN veya position daha kesin olabilir. Timezone kontrol edilmelidir. Recovery ayrı instance üzerinde test edilmelidir. Validation olmadan promote yapılmamalıdır.

Time Zone'u Kontrol Etmemek

UTC ve local saat karışıklığı yanlış recovery target oluşturabilir. Logların timezone offset taşıması gerekir. Daylight saving kullanılan bölgeler ayrıca risklidir. Application, database ve cloud console farklı zone gösterebilir. Operasyon standardı belirlenmelidir. Tooling zaman dönüşümünü otomatik yapmalıdır.

Production Üzerine Doğrudan Restore Yapmak

In-place restore mevcut state'i yok edebilir. Olay sonrasındaki doğru transaction'lar kaybolabilir. Forensic analiz zorlaşır. Ayrı recovery instance daha güvenlidir. Yanlış target seçilirse yeniden denenebilir. Cutover validation sonrası yapılmalıdır.

Recovery Target'ı Kontrol Etmeden Promote Etmek

Database target'a ulaşınca hemen writable hâle getirilmemelidir. Hatalı transaction'ın bulunmadığı doğrulanmalıdır. Son doğru transaction da mevcut olmalıdır. Business validation yapılmalıdır. Promotion yeni timeline oluşturabilir. Geri dönüş planı daha zor hâle gelir.

Restore Süresini RTO'ya Dahil Etmemek

RTO yalnızca database start süresi değildir. Backup copy ve log transfer zaman alır. Validation ve cutover da hesaba katılmalıdır. DNS veya application restart gecikebilir. Drill bütün adımları ölçmelidir. Business hedef toplam süre üzerinden değerlendirilmelidir.

Log Replay Hızını Ölçmemek

Eski base backup çok uzun log history gerektirebilir. Replay throughput RTO'nun ana bottleneck'i olabilir. Yalnızca backup restore süresini ölçmek eksik sonuç verir. MB/s veya LSN progress takip edilmelidir. Storage ve CPU kapasitesi test edilmelidir. Base backup sıklığı sonuca göre optimize edilebilir.

Long-Running Transaction'ları İzlememek

Uzun transaction log truncation'ı engelleyebilir. File hızla büyür. Crash recovery süresi uzayabilir. Lock ve MVCC sorunları oluşabilir. Transaction age monitoring kurulmalıdır. Application owner ile otomatik alert paylaşılmalıdır.

Transaction Log ve Backup'ı Aynı Failure Domain'de Tutmak

Aynı disk veya account arızası her iki kopyayı kaybettirebilir. Ransomware shared credential ile backup'ı silebilir. Archive ayrı security boundary içinde tutulmalıdır. Cross-region veya cross-account seçenekleri değerlendirilebilir. Immutable storage ek koruma sağlar. Recovery key erişimi de ayrı planlanmalıdır.

Managed Database PITR'ının Otomatik Olarak Test Edildiğini Varsaymak

Cloud provider servis özelliğinin altyapısını işletir. Kurumun doğru target seçimini ve application cutover'ını provider test etmez. IAM veya KMS problemi restore sırasında ortaya çıkabilir. Regular managed PITR drill gereklidir. Gerçek RTO ölçülmelidir. Backup retention configuration drift izlenmelidir.

Sık Sorulan Sorular

İşlem Günlükleri (Transaction Logs) ve Veri Kurtarma konusunda en sık sorulan sorular çoğunlukla backup ile log, replication ile PITR ve crash recovery ile logical recovery arasındaki farklarda yoğunlaşır. Tek bir database teknolojisine ait kavramların diğer sistemlere doğrudan uygulanmaması gerekir. SQL Server, PostgreSQL ve MySQL farklı log yapıları kullanır. Buna rağmen ortak prensip base backup, kesintisiz değişiklik geçmişi, doğru recovery target ve test edilmiş restore prosedürüdür. Aşağıdaki cevaplar bu temel noktaları günlük operasyon açısından özetler.

Transaction log nedir?

Transaction log database değişikliklerini recovery amacıyla sıralı biçimde kaydeden mekanizmadır. Crash sonrasında committed işlemlerin korunmasına yardımcı olur. Bazı sistemlerde PITR ve replication için de kullanılır. Application veya audit log ile aynı değildir. Log file'ın bulunması backup bulunduğu anlamına gelmez. Retention ve archive ayrıca planlanmalıdır.

WAL nedir?

WAL Write-Ahead Log anlamına gelir. Değişikliğe ait log bilgisinin data page'den önce kalıcı hâle getirilmesi prensibine dayanır. PostgreSQL bu yaklaşımı temel recovery mekanizması olarak kullanır. WAL archiving PITR imkânı sağlar. Segmentlerin kesintisiz korunması gerekir. pg_wal içeriği manuel silinmemelidir.

WAL ile transaction log arasındaki fark nedir?

WAL genel bir write-ahead logging prensibini ifade eder. Transaction log belirli database ürününün bu veya benzer recovery kaydına verdiği isim olabilir. PostgreSQL WAL, SQL Server transaction log terminolojisini kullanır. Yapıları ve backup yöntemleri aynı değildir. Ortak amaç transaction durability ve recovery desteğidir. Ürüne özgü dokümantasyon izlenmelidir.

Redo log ve undo log arasındaki fark nedir?

Redo committed değişikliği yeniden uygulamaya yardımcı olur. Undo tamamlanmamış veya geri alınan işlemin etkisini ortadan kaldırmayı destekler. MySQL InnoDB bu iki kavramı ayrı yapılarla kullanır. İkisi de binary log ile aynı değildir. Binary log PITR ve replication için ayrı role sahiptir. Recovery tasarımı bu ayrımı bilmelidir.

MySQL binary log ne işe yarar?

MySQL binary log database değişiklik event'lerini kaydeder. Replication source olarak kullanılabilir. Full backup sonrasında event'ler replay edilerek PITR yapılabilir. Position veya GTID recovery sınırı belirlemeye yardımcı olur. Retention yeterli olmalıdır. Logların source dışına güvenli archive edilmesi faydalıdır.

Transaction log silinebilir mi?

Transaction log dosyaları manuel olarak silinmemelidir. Database engine hangi kayıtların artık gerekli olmadığını kendi truncation veya retention mekanizmasıyla yönetir. Manuel silme database'in açılamamasına veya recovery chain kaybına yol açabilir. Disk problemi varsa root cause bulunmalıdır. Backup, replica veya long transaction engeli olabilir. Vendor'ın desteklenen cleanup yöntemi kullanılmalıdır.

Transaction log backup nedir?

SQL Server gibi sistemlerde transaction log backup belirli log aralığını ayrı backup file olarak korur. FULL recovery model PITR için bu zinciri kullanır. Log backup full backup'ın yerine geçmez. Backup'lar sıralı ve kesintisiz olmalıdır. Schedule RPO hedefinden türetilmelidir. Restore drill ile doğrulanmalıdır.

Log chain nedir?

Log chain base backup'tan recovery target'a kadar gereken log kayıtlarının kesintisiz sırasıdır. Aradaki eksik segment recovery'yi durdurabilir. Sonraki logların bulunması gap'i çözmez. Archive monitoring continuity kontrol etmelidir. Retention zinciri kapsamalıdır. Restore drill gerçek kullanımını test eder.

Point-in-Time Recovery nedir?

PITR database'i geçmişteki seçilen state'e getirme işlemidir. Uygun backup restore edilir. Loglar hedef zamana veya transaction koordinatına kadar replay edilir. Yanlış DELETE ve UPDATE için çok değerlidir. Recovery ayrı instance üzerinde doğrulanmalıdır. Full rollback yerine selective recovery de yapılabilir.

PITR için full backup gerekli midir?

PITR genellikle bir base veya full backup başlangıç noktası gerektirir. Ardından log history target'a kadar uygulanır. Sadece transaction log dosyalarıyla sıfırdan restore çoğu normal tasarımda yeterli değildir. Managed cloud platform ayrıntıları kullanıcıdan gizleyebilir. Ancak arka planda yine uygun backup state ve değişiklik geçmişi gerekir. Recovery sistemi bu başlangıç noktasını otomatik yönetebilir.

SQL Server'da LSN nedir?

LSN SQL Server transaction log kayıtlarının sırasını tanımlar. Backup setleri hangi LSN aralığını kapsadığını metadata içinde taşır. Restore zinciri bu koordinatlarla doğrulanır. Missing LSN interval log chain problemidir. PITR ve forensic analysis için faydalıdır. Backup catalog LSN bilgisini korumalıdır.

PostgreSQL'de WAL nasıl kullanılır?

PostgreSQL WAL crash recovery ve replication için temel log mekanizmasıdır. PITR için WAL archiving etkinleştirilebilir. Base backup restore edildikten sonra archived WAL segmentleri replay edilir. restore_command segmentleri recovery ortamına getirir. Timestamp, LSN veya named restore point target olabilir. Timeline bilgisi promotion sonrasında önemlidir.

MySQL'de binlog ile veri nasıl kurtarılır?

Önce olaydan önceki uygun backup restore edilir. Backup sonrasındaki binary log file'ları belirlenir. mysqlbinlog ile event'ler hedef position veya zamana kadar uygulanır. Hatalı transaction'dan önce durulur. Recovered data doğrulanır. Production'a full cutover veya selective transfer yapılabilir.

Yanlış DELETE işlemi geri alınabilir mi?

Commit edilmemiş transaction normal ROLLBACK ile geri alınabilir. Commit edilmiş yanlış DELETE için backup ve PITR gerekebilir. Recovery instance olay öncesi state'e getirilir. Silinen row'lar oradan çıkarılabilir. Bütün production'ı geriye almak zorunlu değildir. Olay sonrası doğru transaction'lar selective recovery ile korunabilir.

Transaction log ne kadar süre saklanmalıdır?

Tek bir standart süre yoktur. Recovery window, incident detection süresi ve business ihtiyacı belirleyicidir. Base backup sıklığı da hesaba katılır. Günlük log volume storage maliyetini etkiler. Güvenlik payı eklenmelidir. KVKK ve veri retention politikaları ayrıca değerlendirilmelidir.

Replication veri kurtarma için yeterli midir?

Hayır, replication backup yerine geçmez. Yanlış transaction replica'ya da taşınır. Replica high availability sağlar. PITR historical recovery state sunar. Immutable backup ve log archive ayrı korunmalıdır. İki yaklaşım birlikte kullanılmalıdır.

Restore testi ne sıklıkla yapılmalıdır?

Sıklık database kritikliği ve değişim hızına göre belirlenmelidir. Kritik sistemlerde düzenli otomatik restore drill güçlü yaklaşımdır. Büyük version veya architecture değişikliği sonrasında ek test yapılmalıdır. Random recovery target kullanılabilir. RTO ve RPO ölçülmelidir. Başarısız drill production incident gibi aksiyon gerektirmelidir.

İşlem Günlükleri ve Veri Kurtarma Hakkında Ek Sık Sorulan Sorular

Kurumsal database ekipleri recovery tasarımını yalnızca teknik backup ayarı olarak değil iş sürekliliği yeteneği olarak değerlendirmelidir. Transaction log yedekleme sıklığı, retention ve archive location doğrudan RPO hedefini etkiler. Recovery süresini ise base backup boyutu, log replay hacmi, validation ve cutover belirler. Bu nedenle veritabanı veri kurtarma ve DBA danışmanlığı yakınımda şeklinde çözüm arayan kurumların yalnızca “backup kurulumu” değil ölçülebilir restore drill ve recovery runbook desteğini de değerlendirmesi faydalıdır. Aşağıdaki sorular bu kararı daha net hâle getirir.

İşlem günlükleri (Transaction Logs) nedir ve veri kurtarma süreçlerinde nasıl kullanılır?

Transaction log database üzerindeki değişiklikleri sıralı biçimde kaydeden recovery mekanizmasıdır. Crash sonrasında committed transaction'ları yeniden oluşturmak için kullanılabilir. Uygun backup stratejisiyle birlikte point-in-time recovery imkânı sağlar. SQL Server transaction log backup, PostgreSQL WAL archive ve MySQL binary log bu amaca farklı biçimlerde hizmet eder. Logların kesintisiz ve güvenli storage üzerinde korunması gerekir. Application log veya audit log transaction recovery kaynağının yerine geçmez.

Transaction Log kullanılarak veritabanı belirli bir zamana (Point-in-Time Recovery) nasıl geri yüklenir?

Önce hedef zamandan önceki uygun full veya base backup seçilir. Backup ayrı recovery instance üzerinde restore edilir. Sonraki transaction log, WAL veya binlog kayıtları hedef transaction'a kadar sırayla uygulanır. Timestamp yerine mümkün olduğunda LSN, GTID veya binlog position gibi daha kesin koordinatlar kullanılabilir. Target'a ulaşıldığında database read-only doğrulanmalıdır. Validation tamamlanmadan production cutover yapılmamalıdır.

Transaction Log yedekleri ne sıklıkla alınmalı ve saklama politikaları nasıl belirlenmelidir?

Backup frekansı business RPO hedefinden türetilmelidir. Beş dakikalık veri kaybı toleransı bulunan sistemde saatlik log backup yeterli olmaz. Retention süresi incident detection ve recovery hazırlık zamanından daha uzun olmalıdır. Günlük log generation storage maliyeti için ölçülmelidir. Archive production dışındaki bağımsız failure domain'de tutulmalıdır. Lifecycle policy düzenli restore drill ile doğrulanmalıdır.

SQL Server ve PostgreSQL gibi veritabanlarında işlem günlükleriyle veri kaybı nasıl en aza indirilir?

SQL Server FULL recovery modelinde sık log backup ve tail-log prosedürü düşük RPO sağlar. PostgreSQL tarafında sürekli WAL archive ve güncel base backup benzer hedefe hizmet eder. Her iki sistemde archive production dışına taşınmalıdır. Missing segment ve backup gecikmesi monitoring ile anında tespit edilmelidir. Recovery target kesin koordinatlarla belirlenmelidir. Düzenli restore drill gerçek RPO ve RTO'nun planlanan hedefi karşılayıp karşılamadığını göstermelidir.

İşlem günlükleri ve veritabanı kurtarma konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Veritabanı veri kurtarma ve DBA danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca teorik backup anlatan hizmetlere değil uygulamalı restore ve PITR çalışmaları sunan kaynaklara bakmak faydalıdır. Diyarbakır'da yazılım ve teknik topluluk çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/about adresini ziyaret edebilirsiniz. Uygulamalı topluluk ve proje çalışmalarına https://www.diyarbakiryazilim.com.tr/projects üzerinden ulaşabilirsiniz. Eğitim ortamında gerçek production verisi yerine izole demo database ve sahte veri kullanılmalıdır. En faydalı çalışma yanlış DELETE oluşturup backup ve transaction log zinciriyle belirli bir noktaya gerçek recovery yapmayı içeren laboratuvar senaryosudur.

Sonuç

İşlem Günlükleri (Transaction Logs) ve Veri Kurtarma, bir database'in yalnızca yedeklenmesini değil gerçekten geri getirilebilir olmasını hedefleyen operasyon disiplinidir. Transaction log, WAL ve binlog yapıları crash recovery, replication ve PITR süreçlerinde farklı roller üstlenir. Sağlam strateji uygun base backup, kesintisiz log chain, production dışındaki güvenli archive, doğru recovery target ve düzenli restore drill üzerine kurulmalıdır. Benim gerçek projelerde en değerli bulduğum metrik “backup başarılı mı?” yerine “şu an hangi son transaction'a kadar ve kaç dakika içinde geri dönebiliriz?” sorusunun cevabıdır. Bu soruya ölçülmüş ve düzenli test edilen bir cevap verebiliyorsanız recovery tasarımınız çok daha anlamlı hâle gelir. Diyarbakır Yazılım Topluluğu içindeki proje ve teknik paylaşım çalışmalarını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresine, topluluk hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresine göz atabilirsiniz. En iyi başlangıç adımı bugün kritik bir database seçip son backup'ının gerçekten restore edilip edilmediğini test etmektir.