Sunucuda Veri Saklama Süreleri: Günlükler, Yedekler ve Uyum

Sunucunuzda üç yıllık erişim günlüğü, iki yıllık yedek ve ne zamandan kalma olduğu belirsiz veritabanı kopyaları var. Hiçbiri silinmiyor çünkü kimse silme kararını vermek istemiyor.

Bu yazı, saklama sürelerini bilinçli belirlemeyi ele alıyor.

İki Karşıt Baskı

Saklama süresi kararı iki yönlü bir gerilim içerir:

Sağ sütundaki ikinci satır çoğu kişinin düşünmediği bir gerçeği içerir: sakladığınız her veri, bir gün sızabilecek bir veridir — ve sildiğiniz veri hiçbir zaman sızmaz.

Bu, gereksiz veriyi tutmanın yalnızca maliyet değil risk de ürettiği anlamına gelir.

Veriyi Sınıflandırmak

Tek bir saklama süresi tüm veriye uygulanamaz:

1. Kişisel veri içerenler. En kısa süre, en sıkı kural.
2. İşlem kayıtları. Yasal süre belirleyici.
3. Teknik günlükler. Operasyonel ihtiyaca göre.
4. Toplu istatistikler. Uzun tutulabilir.
5. Geçici dosyalar. Günler.

Dördüncü madde pratik bir çözüm sunar: aylık ziyaret sayısını bilmek için o ziyaretçilerin tekil kayıtlarını saklamanız gerekmez — özet üretip ham veriyi silmek hem uyumlu hem yeterlidir.

Bu dönüşüm, uzun vadeli analiz ihtiyacını gizlilik gerekliliğiyle uzlaştıran en zarif yoldur.

Sunucu Günlükleri

Erişim ve hata günlükleri özel dikkat gerektirir:

• IP adresi kişisel veri sayılabilir.
• Adres satırında hassas bilgi olabilir.
• Hata günlükleri form verisi içerebilir.
• Boyutları hızla büyür.

İkinci madde sık gözden kaçar: sorgu parametresiyle taşınan bir e-posta adresi veya kimlik numarası, erişim günlüğüne düz metin olarak yazılır ve orada aylarca durur.

Bu yüzden hassas bilgiler asla adres satırında taşınmamalıdır. Taşınıyorsa günlükte maskeleme yapılmalıdır.

Üçüncü madde ise hata ayıklama ayarlarıyla ilgilidir. Ayrıntılı hata kaydı açıkken form içerikleri günlüğe düşebilir — şifre alanları dahil.

Yedek Saklama

Yedekler farklı bir mantıkla saklanır:

Bu kademeli yapı hem kurtarma esnekliği hem maliyet dengesi sağlar: yakın geçmişte günlük hassasiyet, uzak geçmişte aylık hassasiyet yeterlidir.

Ancak yedeklerde önemli bir uyum sorunu vardır ve genellikle atlanır — bir kullanıcının verisini silseniz bile, o veri yedeklerde durmaya devam eder.

Bu durumda uygulanan yaklaşım, yedeklerin de bir saklama süresi olması ve süresi dolduğunda tamamen imha edilmesidir. Yedekten geri dönüş yapılırsa, silinmiş kayıtların tekrar silinmesi gerekir.

Silmeyi Otomatikleştirmek

Elle silme kararı hiçbir zaman verilmez. Otomasyon şarttır:

1. Her veri türü için süre tanımlayın.
2. Zamanlanmış temizlik görevi kurun.
3. Silinen miktarı kaydedin.
4. Beklenmedik miktarda uyarı üretin.
5. Önce arşivleyip sonra silin. Kritik verilerde.

Dördüncü madde bir güvenlik ağıdır: normalde günde bin kayıt silen bir görevin bir gün bir milyon kayıt silmesi, bir yapılandırma hatasının işaretidir — ve durdurulması gerekir.

Bu kontrol olmadan hatalı bir tarih hesabı, saklanması gereken tüm veriyi bir gecede silebilir.

Nasıl Silinmeli?

Silme işleminin kendisi de bir karardır:

• Yumuşak silme: Kayıt işaretlenir, durur.
• Gerçek silme: Kayıt kaldırılır.
• Anonimleştirme: Kişisel alanlar temizlenir, kayıt kalır.

Üçüncü seçenek çoğu senaryoda en dengeli olanıdır: bir siparişin kişisel bilgilerini temizleyip tutarını ve tarihini korumak, hem gizliliği sağlar hem muhasebe bütünlüğünü bozmaz.

Birinci seçenek ise bir yanılgı üretir. Yumuşak silme, veriyi silmez — yalnızca gizler. Gizlilik yükümlülüğü açısından silme sayılmaz.

Politikayı Yazmak

Saklama kararları belgelenmelidir:

Üçüncü satır denetimlerde belirleyicidir: bir sürenin neden seçildiği yazılı değilse, o süre keyfi görünür — yasal gereklilik, operasyonel ihtiyaç veya sözleşme maddesi olarak dayanak gösterilmelidir.

Bu belge aynı zamanda ekip için bir referanstır. Yeni bir veri türü eklendiğinde ona da bir süre atanması gerektiğini hatırlatır.

Teknik Uygulama

Sunucu tarafında kurulacak mekanizmalar:

1. Günlük döndürme ve saklama sayısı.
2. Yedek temizleme görevi.
3. Veritabanı temizlik sorguları.
4. Geçici dosya temizliği.
5. Nesne depolama yaşam döngüsü kuralları.

Beşinci madde ek bir kolaylık sağlar: nesne depolama sistemleri belirli yaştaki dosyaları otomatik silen kurallar tanımlamaya izin verir — ayrı bir temizlik betiği yazmaya gerek kalmaz.

Bu kuralları kendi yapılandırmanızda tanımlayabildiğiniz VDS sunucu kiralama hizmeti ortamında, günlük döndürme ve zamanlanmış temizlik doğrudan sistem seviyesinde kurulabilir.

Sonuç

Veri saklama kararında gözden kaçan taraf risktir: sakladığınız her veri bir gün sızabilecek bir veridir, sildiğiniz veri hiçbir zaman sızmaz. Tek bir süre tüm veriye uygulanamaz — kişisel veri, işlem kaydı ve teknik günlük ayrı ele alınmalıdır. Uzun vadeli analiz için ham veri saklamak yerine özet üretin. Ve silme görevinize miktar uyarısı ekleyin: normalde bin kayıt silen bir görevin bir milyon silmesi, hatalı bir tarih hesabının işaretidir.

Sıkça Sorulan Sorular (SSS)

Ne kadar süre saklamalıyım?

Veri türüne göre değişir. Kişisel veri içerenleri en kısa, işlem kayıtlarını yasal süre boyunca, teknik günlükleri operasyonel ihtiyaca göre tutun. Uzun vadeli analiz için ham veri yerine özet istatistik üretin — aylık ziyaret sayısını bilmek için tekil kayıtları saklamanız gerekmez.

Sunucu günlüklerinde risk var mı?

Var. IP adresi kişisel veri sayılabilir ve daha önemlisi, sorgu parametresiyle taşınan bir e-posta veya kimlik numarası erişim günlüğüne düz metin yazılır. Hassas bilgileri adres satırında taşımayın; taşınıyorsa günlükte maskeleyin.

Silinen veri yedeklerde kalıyor, ne yapmalıyım?

Yedeklere de saklama süresi tanımlayın ve süresi dolduğunda tamamen imha edin. Ayrıca yedekten geri dönüş yaparsanız, o sırada silinmiş olan kayıtların tekrar silinmesi gereken bir adım olarak prosedürünüzde yer almalıdır.

Silmek yerine anonimleştirebilir miyim?

Çoğu senaryoda bu en dengeli çözümdür. Bir siparişin kişisel bilgilerini temizleyip tutarını ve tarihini korumak, hem gizliliği sağlar hem muhasebe bütünlüğünü bozmaz. Ancak yumuşak silme yeterli değildir — o veriyi silmez, yalnızca gizler.