Deploynix Üzerinde Laravel Uygulamaları İçin 3-2-1 Yedekleme Kuralı

Bir uygulama inşa etmek aylardan ziyade, her şeyi kaybetmek ise sadece birkaç saniye sürer. Bozuk bir veritabanı migrasyonu, WHERE ifadesi olmadan yapılan kazara bir DELETE, tehlikeye giren bir sunucu, bulut sağlayıcı arızası veya yanlış komut çalıştıran iyi niyetli bir takım üyesi. Veri kaybı senaryoları çeşitlidir, ancak kurtarma stratejisi on yıllardır tutarlıdır: 3-2-1 yedekleme kuralı.

Bu kural hatırlanması kolay ve hemen hemen her başarısızlık senaryosuna karşı koruma sağlayacak kadar kapsamlıdır. Bu rehber, kuralı açıklar, Laravel uygulamanız için Deploynix kullanarak nasıl uygulayacağınızı gösterir ve felaketten kurtulan takımlar ile kurtulamayan takımları ayıran uygulamaları kapsar.

3-2-1 Yedekleme Kuralı Nedir?

3-2-1 yedekleme kuralı, fotoğrafçı Peter Krogh tarafından formüle edilmiştir ve zamanla veriyi önemseyen her alanda benimsenmiştir. Kural şunları ifade eder:

• Verinizin 3 kopyası (birincil ve iki yedek).
• 2 farklı türde depolama ortamı.
• 1 kopya yerel ağ dışında depolanmalıdır (birincil veriden coğrafi olarak ayrı).

Kuralın her bir unsuru, belirli bir arıza türüne karşı koruma sağlar.

Üç kopya, medya arızasına karşı koruma sağlar. Bir kopya bozulursa veya kaybolursa, iki tane daha vardır. Üçünün aynı anda başarısız olma olasılığı ihmal edilebilir derecede düşüktür.

İki medya türü, medya spesifik arızalara karşı koruma sağlar. Yedeklerinizin tamamı aynı tür depolama üzerinde ise, sistematik bir arıza (belirli bir SSD modelini etkileyen bir firmware hatası veya bulut sağlayıcısının depolama alt sistemindeki bir arıza gibi) tüm kopyaları aynı anda yok edebilir.

Bir yerel dışı kopya, fiziksel felaketlere karşı koruma sağlar. Veri merkezinizdeki bir yangın, sel veya zorla girme tüm sunucuların yok olmasına neden olabilir. Yerel dışı bir kopya, en kötü senaryoda bile kurtulabileceğinizden emin olmanızı sağlar.

3-2-1 Kuralını Laravel Uygulamalarına Uygulamak

Laravel uygulamanız için kritik veriler şunları içerir:

• Veritabanı içerikleri: Kullanıcı verileri, uygulama durumu ve iş mantığını içeren MySQL, MariaDB veya PostgreSQL veritabanınız.
• Yüklenen dosyalar: Diskte veya nesne depolamada saklanan kullanıcı tarafından oluşturulan içerik.
• Çevre yapılandırması: .env dosyanız ve herhangi bir sunucuya özel yapılandırma.
• Uygulama kodu: Kaynak kodunuz (zaten Git ile yedeklenmiş olsa da stratejinize dahil edilmesi gereken bir öğe).

3-2-1 kuralını bu bileşenlere uygulayalım.

Kopya 1: Ana Veri (Canlı Sunucunuz)

İlk kopyanız canlı datadır ve Deploynix sunucunuzda bulunmaktadır. Bu, kullanıcılarınıza hizmet veren birincil kopyadır. DigitalOcean, Vultr, Hetzner, Linode veya AWS EC2 gibi sunucunun diskinde yaşamaktadır.

Bu kopya en erişilebilir ama aynı zamanda en savunmasız olandır. Kazara silme, uygulama hataları, sunucu ihlalleri ve donanım arızasına maruz kalabilir.

Kopya 2: Otomatik Sunucu Yedeği

İkinci kopyanız, bir program dahilinde çalışan ve uygulama verilerinizden ayrı depolanan otomatik bir yedek olmalıdır.

Deploynix ile veritabanı yedeklemeleri:

Deploynix, bir program dahilinde çalışan otomatik günlük veritabanı yedeklemeleri sunmaktadır. Görevli operasyonlardan önce ek bir koruma sağlamak için panelden manuel yedeklemeler de oluşturabilirsiniz.

Bu yedekler, MySQL/MariaDB için mysqldump veya PostgreSQL için pg_dump kullanılarak veritabanınızın tutarlı bir anlık görüntüsünü yakalar. Sıkıştırılmış olarak yapılandırmanıza göre depolanır.

Dosya yedeklemeleri:

Kullanıcı tarafından yüklenen dosyalar, sunucunun dosya sistemine kaydediliyorsa, ayrı bir yedekleme stratejisine ihtiyacınız vardır. Laravel’in public veya local diskini kullanıyorsanız, bu dosyalar sunucuda yaşamaktadır ve veritabanınızla birlikte yedeklenmelidir.

Dosya depolama alanını nesne depolama hizmetine (DigitalOcean Spaces veya AWS S3 gibi) taşıyarak Laravel’in s3 dosya sistemi sürücüsünü kullanmayı düşünün. Bu yaklaşım, dosya depolamanızı sunucudan ayırır ve nesne depolama hizmetlerinin kendi replikasyonunu ele aldığından dolayı sezgisel bir yedeklilik sağlar.

Kopya 3: Yerel Dışı Yedekleme için Nesne Depolama

Üçüncü kopyanız, tamamen farklı bir konumda, ideal olarak farklı bir sağlayıcıda saklanmalıdır. Burada Deploynix’in yedekleme depolama entegrasyonu devreye girer.

Yerel dışı yedekleme depolama yapılandırması:

Deploynix, yedeklerinizi göndermeyi destekler:

• AWS S3: Yedekleri dünya çapında herhangi bir AWS bölgesinde saklayın.
• DigitalOcean Spaces: DigitalOcean ile entegre nesne depolama.
• Wasabi: Maliyet etkin S3 uyumlu depolama.
• Özel S3 uyumlu: S3 API’sini destekleyen herhangi bir sağlayıcı.

Yerel dışı bir konum seçimi:

Bölgesel felaketler, sağlayıcıya özgü kesintiler ve veri merkezi arızalarının önüne geçmek için yerel dışı kopya, birincil sunucunuzdan coğrafi olarak uzak olmalıdır. Sunucunuz New York’taki bir DigitalOcean veri merkezindeyse, yerel dışı yedeğinizi Frankfurt’taki bir AWS S3 havuzuna veya Amsterdam’daki bir Wasabi havuzuna depolayın.

İki Medya Türünün Uygulanması

Bulut barındırma bağlamında “iki medya türü” ifadesi yaratıcı bir yorum gerektirir. Yedekleme DVD’leri yakmaya çalışmayacaksınız. Bunun yerine, “medya türlerini” “farklı arıza modlarına sahip depolama sistemleri” olarak düşünün.

Seçenek 1: Sunucu diski + Nesne depolama

Ana veriniz sunucunun blok depolamasında (SSD) yer alırken, yedeğiniz nesne depolamada (S3 uyumlu) olmalıdır. Bu sistemlerin temel mimarileri ve arıza modları farklıdır.

Seçenek 2: Nesne depolama + Farklı bir bulut sağlayıcısı

Eğer ana veriniz bir bulut sağlayıcısında ise, yedekleme için farklı bir sağlayıcı kullanmalısınız. DigitalOcean’da barındırıyorsanız, AWS S3’e yedekleme yapın. Hetzner’da barındırıyorsanız, Wasabi’ye yedekleme yapın. Bu, sağlayıcılar arasında riskinizi çeşitlendirir.

Seçenek 3: Bulut + Yerel/ön uç

En kritik veriler için, yedekleri periyodik olarak yerel bir NAS veya ön uç sunucuya indirin. Bu, medya türleri arasında en çeşitli ayırımı sağlar. Çoğu uygulama için aşırı bir önlem olabilir ancak katı veri saklama gereksinimi olan işletmeler için önemlidir.

Pratik Bir Uygulama Planı

Deploynix üzerinde bir Laravel uygulaması için 3-2-1 yedeklemesini uygulamak için somut bir plan:

Adım 1: Otomatik Veritabanı Yedeklemelerini Yapılandırın

Deploynix panelinde sunucunuzun yedekleme ayarlarına gidin:

1. Veritabanınızı seçin.
2. Yerel dışı depolama sağlayıcınızı yapılandırın (AWS S3, DigitalOcean Spaces, Wasabi veya özel).
3. Deploynix, sabit bir program dahilinde otomatik günlük yedeklemeler gerçekleştirir. Riskli işlemlerden önce ek bir koruma için panelden manuel bir yedek oluşturabilirsiniz.
4. Yedekler, bir büyükbaba-baba-oğul politikası çerçevesinde saklanır (günlük, haftalık ve aylık koruma süreleri).

Adım 2: Dosya Yedeklemelerini Yapılandırın

Uygulamanız kullanıcı yüklemelerini yerel dosya sisteminde saklıyorsa:

Seçenek A (Tavsiye Edilir): Dosya depolamayı nesne depolama alanına taşıyın.

Laravel dosya sistemi yapılandırmanızı S3 uyumlu bir disk kullanacak şekilde güncelleyin:

// config/filesystems.php
'disks' => [
    'uploads' => [
        'driver' => 's3',
        'key' => env('AWS_ACCESS_KEY_ID'),
        'secret' => env('AWS_SECRET_ACCESS_KEY'),
        'region' => env('AWS_DEFAULT_REGION'),
        'bucket' => env('AWS_BUCKET'),
    ],
],

Nesne depolamada saklanan dosyalar, sağlayıcının altyapısı içinde otomatik olarak çoğaltılmaktadır ve bu da size doğası gereği bir yedeklilik sağlar.

Seçenek B: Dosya dizinlerini yedeğe dahil edin.

Eğer dosyaların sunucuda kalması gerekiyorsa, yükleme dizinini arşivleyen ve yerel dışı depolamanıza gönderen bir cron görevi veya dağıtım tetikleyicisi yapılandırın:

tar -czf /tmp/uploads-$(date +%Y%m%d).tar.gz /home/deploynix/your-site/storage/app/public
aws s3 cp /tmp/uploads-$(date +%Y%m%d).tar.gz s3://your-backup-bucket/files/
rm /tmp/uploads-$(date +%Y%m%d).tar.gz

Adım 3: Çevre Yapılandırmasını Yedekleyin

.env dosyanız ve sunucu yapılandırmaları küçüktür ama kritik öneme sahiptir. Bunları kaybetmek, her API anahtarını, veritabanı kimlik bilgilerini ve hizmet yapılandırmasını hafızanızdan yeniden oluşturmanız gerektiği anlamına gelir.

Pratik yaklaşımlar:

• Üretim çevre değişkenlerinin bir kopyasını yetkili ekip üyelerinin erişebileceği bir şifre yöneticisinde saklayın (1Password, Bitwarden).
• Laravel’in şifrelenmiş çevre dosyalarını kullanın (php artisan env:encrypt) ve şifrelenmiş dosyayı deposuna ekleyin.
• Deploynix, çevre değişkenlerinizi platformunda saklayarak, sunucunuz dışında ek bir kopya sağlar.

Adım 4: Kodu Sürüm Kontrolünde Doğrulayın

Bu gayet açık olmalı, ancak uygulama kodunuzun GitHub, GitLab, Bitbucket veya başka bir sağlayıcıda yer alan bir Git deposuna kaydedildiğinden emin olun. Kod deponuz uygulama mantığınızın etkili bir yerel dışı yedeğidir. Deploynix, GitHub, GitLab, Bitbucket ve özel Git sağlayıcılarıyla dağıtım için entegre olmaktadır.

Yedeklerinizi Test Edin

Test edilmemiş bir yedek, bir dilekten başka bir şey değildir. Düzenli kurtarma testleri, her yedekleme stratejisinin en önemli ve en ihmal edilen parçasıdır.

Aylık Kurtarma Tatbikatı

Her ay, aşağıdaki işlemleri gerçekleştirmek için bir tatbikat planlayın:

1. Yerel dışı depolamanızdan en son yedeği indirin.
2. Bunu bir test ortamına geri yükleyin.
3. Veri bütünlüğünü doğrulayın (kayıt sayıları, güncel kayıtlar, ana veri noktaları).
4. Süreçteki sorunları veya iyileştirme gereksinimlerini belgeleyin.

Kurtarma Sonrası Doğrulanacaklar

• Kayıt sayıları: Ana tablolardaki (kullanıcılar, siparişler vb.) kayıt sayısını üretimle karşılaştırın.
• Son veriler: En son kayıtların mevcut olduğunu ve doğru olduğunu doğrulayın.
• İlişkiler: Yabancı anahtar ilişkilerinin sağlam olduğunu kontrol edin.
• Dosyalar: Yedeklediğiniz yüklenen dosyaların erişilebilir ve bozulmamış olduğunu kontrol edin.
• Uygulama işlevselliği: Kurtarılan veritabanına karşı Laravel uygulamasını başlatın ve temel özelliklerin çalıştığını doğrulayın.

Otomasyon

Kurtarma testini otomatik hale getirmeyi düşünün. Bunun için bir betik oluşturabilirsiniz:

1. En son yedeği indirin.
2. Bunu test veritabanına geri yükleyin.
3. Bir dizi doğrulama sorgusu çalıştırın.
4. Sonuçları ekibinize rapor edin.

Yedek Tutma Politikaları

Yedekleri ne kadar süreyle saklamalısınız? Cevap, veri kurtarma ihtiyaçlarınıza ve düzenleyici gereksinimlerinize bağlıdır.

Minimum önerilen tutma süresi:

• Günlük yedekler: 30 gün saklayın.
• Haftalık yedekler: 12 hafta saklayın.
• Aylık yedekler: 12 ay saklayın.

Bu “büyükbaba-baba-oğul” yaklaşımı, yakın sorunlar için hassas bir kurtarma sağlarken (geçtiğimiz aydaki günlük yedekler) daha eski sorunlar için daha geniş bir kapsama (geçen yılki aylık yedekler) sahip olmanızı sağlar.

Uyum göz önünde bulundurularak aşağıdakiler önemlidir:

• GDPR belirli tutma süreleri talep etmez, ancak kişisel verileri ne kadar süre ile sakladığınıza dair bir gerekçe sunulmasını zorunlu kılar.
• SOC 2 genellikle en az bir yıl boyunca denetim günlükleri ve yedekler talep eder.
• HIPAA en az altı yıl yedek saklanmasını talep eder.
• PCI DSS en az bir yıl boyunca denetim geçmişinin saklanmasını gerektirir.

Yaşam döngüsü politikaları:

AWS S3 kullanıyorsanız, yaşam döngüsü politikalarını yapılandırarak otomatik olarak:

• 30 günden eski günlük yedekleri S3 Sık Kullanım Dışı’na geçirin.
• 6 aydan eski aylık yedekleri S3 Glacier’a geçirin.
• Tutma politikanızı aşan yedekleri silin.

Bu, depolama maliyetlerini azaltırken tarihsel yedeklere erişimi sürdürmenizi sağlar.

Felaket Kurtarma Senaryoları

Yaygın felaket senaryolarını ve 3-2-1 kuralının sizi nasıl koruduğunu inceleyelim.

Senaryo 1: Kazara veri silme.

Bir geliştirici üretimde yıkıcı bir sorgu çalıştırıyor. En son yedeğiniz (kopya 2), etkilenen verileri geri yüklemenizi sağlar. Eğer yedek çok eski ise, saatlik yedekleriniz veri kaybını en aza indirger.

Senaryo 2: Sunucu ihlali.

Bir saldırgan verilerinize erişim kazanır ve onları şifreler (fidye yazılımı). Yerel dışı yedeğiniz (kopya 3), farklı kimlik bilgilerinde saklandığı için saldırgan buna erişemez. Deploynix üzerinden yeni bir sunucu oluşturun, yedeğinizi geri yükleyin, tüm kimlik bilgilerini değiştirin ve ihlali araştırın.

Senaryo 3: Bulut sağlayıcı arızası.

Barındırıcı sağlayıcınız uzun süreli bölgesel bir arıza yaşıyor. Yerel dışı yedeğiniz başka bir sağlayıcıda olduğu için, yeni bir sunucu tedarik edebilir ve uygulamanızı geri yükleyebilirsiniz. Deploynix, DigitalOcean, Vultr, Hetzner, Linode, AWS ve özel sunucularla destekliyor, bu da size seçenekler sunuyor.

Senaryo 4: Bozuk dağıtım.

Bir migrasyon yanlış gitmiş ve verileri bozulmuş. Günlük yedeğiniz, önceki dağıtım durumuna geri dönmenizi sağlar. Bu bağlamda Deploynix’in dağıtımlar için geri alma özelliği ile veritabanı yedekleriniz birbirini tamamlar.

Sonuç

3-2-1 yedekleme kuralı, basit, etkili ve veri erişilebilirliğine yönelik temel riskleri ele aldığı için on yıllardır varlığını sürdürmektedir. Deploynix’deki Laravel uygulamanız için bunu uygulamak, şu anlama gelir:

1. Canlı sunucunuz birincil kopyayı tutar.
2. Otomatik Deploynix yedeklemeleri ikinci kopyayı oluşturur.
3. AWS S3, DigitalOcean Spaces, Wasabi veya başka bir S3 uyumlu sağlayıcıda yerel dışı depolama üçüncü kopyayı farklı bir altyapıda oluşturur.

Kural sizin temel yapınızı oluşturur, ancak etrafındaki uygulamalar da en az onun kadar önemlidir. Kurtarma işlemlerinizi her ay test edin. Kurtarma prosedürlerinizi belgeleyin. Tutma politikalarınızı her üç ayda bir gözden geçirin. Ekibinizi kurtarma süreci konusunda eğitin.

Veri kaybı her zaman “ne zaman” olduğunu ifade eder, “eğer” değil. 3-2-1 kuralı, başınıza geldiğinde bunun bir felaket değil, bir rahatsızlık olmasını sağlar.