Veri Arşivleme Nedir? Eski Veri Canlı Sistemden Arşive Nasıl Taşınır?

Üçü de veriyle ilgilidir ama farklı soruya cevap verir. Yedek "bozulursa geri dönebilir miyim?" sorusuna, arşiv "canlı sistemi şişirmeden eski kaydı saklayabilir miyim?" sorusuna, silme/imha ise "bu veri artık bulunmamalı mı?" sorusuna cevap verir.

Yedeği arşiv yerine koyamazsınız. Yedek canlı veriyi olduğu gibi kopyaladığı için eski kayıtlar hem canlı sistemde hem yedekte yer tutmaya devam eder; arşiv ise eski dönemi canlıdan çıkarır ve sorguları genellikle hafifletir.

Tersi de geçerlidir: arşiv yedek yerine geçmez. Arşiv tablosu ya da dosyası bozulursa elinizde başka kopya kalmaz; bu yüzden arşivin kendisi de yedek politikasına girer ve geri yükleme denemesiyle sınanır.

Bir tablonun eski kayıtlarını arşive almadan önce aşağıdaki soruları sırayla cevaplayın. Cevaplardan biri "bilmiyorum" ise taşıma değil, önce o bilgiyi toplama işi başlar; yanlış arşivlenen kaydı sonradan bulmak ve geri taşımak zaman alır.

1. Son erişim ya da son güncelleme tarihi biliniyor mu? Bilinmiyorsa "eski" kavramı tahmindir; önce bu tarihi tablodaki tarih sütunundan veya erişim kayıtlarından çıkarın.
2. Raporlar ya da uygulama ekranları bu dönemi hâlâ okuyor mu? Okuyorsa taşımadan önce rapor sorgusunun arşivi de görmesini planlayın.
3. Yasal ya da sözleşmesel saklama yükümlülüğü var mı? Varsa süreyi ve dayanağını yazılı kaydedin; süreyi tahminle değil ilgili mevzuattan veya sözleşmeden alın.
4. Kişisel veri içeriyor mu? İçeriyorsa arşiv için saklama süresi ve imha adımı baştan belli olmalı (aşağıdaki KVKK bölümüne bakın). Kayıtlar yinelenen ya da hatalıysa önce onları temizleyin (bağlantı sayfa sonundaki kutuda).
5. Yabancı anahtarla bağlı tablolar var mı? Varsa ana kaydı ve ona bağlı kayıtları aynı tarih kuralıyla birlikte taşıyın.
6. Geri getirme ihtiyacı ve kabul edilebilir bekleme süresi tanımlı mı? "Dakikalar mı, günler mi?" cevabı depolama katmanını belirler.
7. Arşivin sahibi kim? Erişim izni, geri yükleme testi ve imha onayı için adı belli bir ekip olmalı.

Arşiv tek bir yer değildir; erişim sıklığı düştükçe veri daha ucuz ama daha yavaş ortamlara kaydırılır. Aşağıdaki tablo ortamları göreli olarak karşılaştırır; sayısal fiyat ve süre sağlayıcıya ve yapılandırmaya göre değiştiği için verilmemiştir.

Katman sınırını verinin yaşı değil okunma sıklığı çizer. Önce son bir yıldaki sorgu ve rapor erişimlerine bakın; sık okunan eski veriyi soğuk katmana göndermek raporları yavaşlatır, hiç okunmayanı sıcakta tutmak ise maliyeti gereksiz artırır.

Örnekler PostgreSQL'in resmî belgesindeki sözdizimine dayanır ve PostgreSQL 14.24'te çalıştırılarak denenmiştir; tablo ve sütun adları örnektir. Kendi ortamınızda önce üretimle aynı yapıdaki bir kopya veritabanında deneyin. Genel bilgi için PostgreSQL nedir? rehberine bakabilirsiniz.

Yol 1: Tabloyu tarihe göre bölümleyin

Tabloyu tarih sütununa göre bölümlemek (partition), tek büyük tabloyu yıllık parçalara ayırmaktır. Eski bir yılı arşivlemek o parçayı tablodan ayırmaktan ibaret kalır; çok sayıda satırı tek tek silmek gerekmez.

-- 1) Bölümlenmiş ana tablo
CREATE TABLE siparis (
    siparis_id     bigint        NOT NULL,
    siparis_tarihi date          NOT NULL,
    musteri_id     bigint        NOT NULL,
    tutar          numeric(12,2),
    PRIMARY KEY (siparis_id, siparis_tarihi)
) PARTITION BY RANGE (siparis_tarihi);

-- 2) Yıllık bölümler (alt sınır dahil, üst sınır hariç)
CREATE TABLE siparis_2023 PARTITION OF siparis
    FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE siparis_2024 PARTITION OF siparis
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
CREATE TABLE siparis_2025 PARTITION OF siparis
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

Birincil anahtar bölüm anahtarını (siparis_tarihi) içermek zorundadır: PostgreSQL belgesine göre bölümlenmiş tabloda birincil anahtar ya da benzersiz kısıtın sütunları, bölüm anahtarı sütunlarının tümünü kapsamalıdır. Bu yüzden anahtar yalnız siparis_id olamaz.

Eski yılı arşivlemek için bölümü ana tablodan ayırıp arsiv şemasına alın. CONCURRENTLY seçeneği (PostgreSQL 14 ve sonrası) ana tabloyu kullanan oturumları engellemeyen daha düşük bir kilit kullanır; işlem bloğu içinde çalışmaz, ana tabloda varsayılan bölüm varsa da kullanılamaz.

-- 3) Arşiv şeması
CREATE SCHEMA IF NOT EXISTS arsiv;

-- 4) 2023 bölümünü ana tablodan ayır (işlem bloğu dışında çalıştırın)
ALTER TABLE siparis DETACH PARTITION siparis_2023 CONCURRENTLY;
-- PostgreSQL 13 ve öncesinde CONCURRENTLY yoktur; kilit seviyesi daha yüksektir:
-- ALTER TABLE siparis DETACH PARTITION siparis_2023;

-- 5) Ayrılan tablo artık bağımsızdır; arsiv şemasına taşıyın
ALTER TABLE siparis_2023 SET SCHEMA arsiv;

Ayrılan tablo bağımsız bir tablo olarak durur ve SET SCHEMA indeksleri ile kısıtlarını da arsiv şemasına taşır. Arşivi ayrıca dışa almak isterseniz COPY ya da pg_dump kullanabilirsiniz; belge bunu bölüm ayrıldıktan sonra yapılabilecek bir işlem olarak anar.

Yol 2: Bölümlenmemiş tabloda parça parça taşıyın

Tablo bölümlenmemişse eski satırları tek bir ifadede silip arşiv tablosuna ekleyebilirsiniz. WITH içindeki DELETE ... RETURNING silinen satırları döndürür, dıştaki INSERT onları arşive yazar; PostgreSQL belgesi aynı yapıyı satır taşıma örneği olarak verir.

-- Örnek tablo
CREATE TABLE islem_log (
    kayit_id      bigint      PRIMARY KEY,
    olusma_zamani timestamptz NOT NULL,
    mesaj         text
);

CREATE SCHEMA IF NOT EXISTS arsiv;
CREATE TABLE arsiv.islem_log (LIKE public.islem_log INCLUDING ALL);

-- Her çalıştırmada en fazla 10000 eski satırı taşır
WITH tasinan AS (
    DELETE FROM public.islem_log
    WHERE kayit_id IN (
        SELECT kayit_id
        FROM public.islem_log
        WHERE olusma_zamani < '2025-01-01'
        ORDER BY kayit_id
        LIMIT 10000
    )
    RETURNING *
)
INSERT INTO arsiv.islem_log
SELECT * FROM tasinan;

Komutu, taşınan satır sayısı sıfır olana kadar (psql'de INSERT 0 0 yanıtı gelene kadar) tekrarlayın. Küçük partiler, tek büyük DELETE'in satırları uzun süre kilitli tutmasını azaltır. Her parti ayrı bir işlem olarak çalıştırılırsa yarıda kalan işlem yalnız o partiyi geri alır.

Taşıma tek ifade olduğundan INSERT hata verirse DELETE de geri alınır; satır arşive yazılmadan canlı tablodan silinmez. Yine de ilk denemeyi kopya veritabanında ve küçük bir LIMIT ile yapın.

Oracle ve SQL Server

Oracle'da EXCHANGE PARTITION, bir bölümü bölümlenmemiş tabloyla veri segmentlerini değiştirerek takas eder; SQL Server'da SWITCH PARTITION, bölümün verisini mevcut ve boş bir tabloya atar. Resmî belgeler: Oracle VLDB kılavuzu ve SQL Server ALTER TABLE.

Kaynaklar: PostgreSQL: Table Partitioning, ALTER TABLE, WITH sorguları.

Arşiv "sonsuza kadar sakla" demek değildir. Kişisel veri içeren bir arşiv tablosunun da bir saklama süresi ve imha adımı olmalıdır; arşivi tasarlarken imhayı sonraya bırakırsanız süresi dolan veriyi bulmak ve silmek zorlaşır.

Aşağıdaki hükümler Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik metninden alıntıdır (Resmi Gazete, 28 Ekim 2017, sayı 30224). Yönetmelik madde 3'e göre 6698 sayılı Kanun'un 7. maddesinin üçüncü fıkrasına ve 22. maddesinin birinci fıkrasının (e) bendine dayanır.

• Madde 7(1): "Kanunun 5 inci ve 6 ncı maddelerinde yer alan kişisel verilerin işlenme şartlarının tamamının ortadan kalkması halinde, kişisel verilerin veri sorumlusu tarafından resen veya ilgili kişinin talebi üzerine silinmesi, yok edilmesi veya anonim hâle getirilmesi gerekir."
• Madde 7(3): "Kişisel verilerin silinmesi, yok edilmesi ve anonim hale getirilmesiyle ilgili yapılan bütün işlemler kayıt altına alınır ve söz konusu kayıtlar, diğer hukuki yükümlülükler hariç olmak üzere en az üç yıl süreyle saklanır."
• Madde 11(2): "Periyodik imhanın gerçekleştirileceği zaman aralığı, veri sorumlusu tarafından kişisel veri saklama ve imha politikasında belirlenir. Bu süre her halde altı ayı geçemez."
• Madde 11(3): "Kişisel veri saklama ve imha politikası hazırlama yükümlülüğü olmayan veri sorumlusu, kişisel verileri silme, yok etme veya anonim hale getirme yükümlülüğünün ortaya çıktığı tarihi takip eden üç ay içinde, kişisel verileri siler, yok eder veya anonim hale getirir."

Pratik karşılığı: arşiv tablosunda kişisel veri varsa saklama süresi sütunu ya da bölüm bazlı imha tarihi tutun, imha işini zamanlayın ve her imhanın kaydını ayrı bir tabloya yazın. Yıllık bölümlerde süresi dolan yılı ayırıp kaldırmak bu işi kolaylaştırır.

Sürenin kendisini mevzuat ya da sözleşme belirler. Bu sayfa vergi ve ticari defter saklama sürelerini vermez; ilgili kanunlardaki güncel süreleri hukuk ya da mali müşavirinizle teyit edin. Bu bölüm hukuki görüş değildir.

Arşivleme sorunları taşıma anında değil, sonradan bir rapor ya da geri yükleme isteğiyle ortaya çıkabilir. Aşağıdaki tablo olası altı durumu belirti, neden ve çözümüyle sıralar; çözümlerin çoğu PostgreSQL örneğindeki yapıyı kullanır.

Arşive giden dönemi raporlar hâlâ okuyorsa en az çabayla çözüm, canlı tablo ile arşiv tablolarını birleştiren bir görünümdür. Rapor görünüme bağlanır; yeni bir yıl arşive girdiğinde yalnız görünüm güncellenir, rapor sorguları değişmez.

CREATE VIEW siparis_tum AS
    SELECT siparis_id, siparis_tarihi, musteri_id, tutar FROM siparis
    UNION ALL
    SELECT siparis_id, siparis_tarihi, musteri_id, tutar FROM arsiv.siparis_2023;

Raporlar veri ambarından okuyorsa kaynak sistemde arşivlenen satır ambardan kaybolmayabilir; bu yükleme yöntemine bağlıdır. Tam yeniden yükleme yapan bir ETL işi, kaynaktan taşınan eski satırı ambardan da silebilir; arşivlemeden önce yükleme kuralını kontrol edin.