Logo Yedekleme ve Geri Dönüş Testi: Veritabanı Yöneticisi Olmayanlar İçin

Kısaca: Logo yedekleme, Logo’nun verilerini tuttuğu SQL Server veritabanının düzenli olarak yedek dosyasına alınması ve bu dosyanın ayrı bir sunucuda gerçekten geri yüklenebildiğinin denenmesidir. Yedek dosyasının var olması yetmez. Geri dönüş testi yapılmamış bir yedek, en çok ihtiyaç duyduğunuz gün açılmayabilir.

Logo iş ortağı olarak projelerimizde gördüğümüz şu: çoğu işletme “yedeğimiz var” der, ama son yedeğin ne zaman alındığını, nerede durduğunu ve geri yüklemenin ne kadar süreceğini bilen kimse yoktur. Bu rehber, veritabanı yöneticisi olmayan BT sorumluları, muhasebe müdürleri ve işletme sahipleri için yazıldı. Yedeklemenin genel mantığını ve RPO/RTO kavramlarını SQL veritabanı yedekleme yazımızda anlattık. Burada Logo kullanan bir işletmenin somut adımlarına odaklanıyoruz.

İçindekiler

• Logo yedeklemesi neyi korur?
• Yedeğiniz gerçekten alınıyor mu? Beş dakikalık kontrol
• Logo yedekleme planı: ne zaman, nereye, kaç kopya?
• Geri dönüş testi adım adım
• Büyük işlemlerden önce elle yedek
• Sık yapılan hatalar
• Logo yedekleme kontrol listesi
• Özet

Logo yedeklemesi neyi korur?

Logo Edge T-Series (eski adıyla Logo Tiger 3) ve Logo Edge N-Series (eski adıyla Logo Netsis 3) gibi Logo ERP ürünleri verilerini Microsoft SQL Server veritabanında tutar. Cari hesaplar, faturalar, stok hareketleri ve muhasebe fişleri bu veritabanındadır. Bu yüzden programın kurulu olduğu klasörü kopyalamak verilerinizi yedeklemez. Yedeklenmesi gereken şey SQL Server’daki veritabanıdır.

Kurulumunuzda birden fazla veritabanı olabilir. Ayrıca özel rapor tasarımları veya entegrasyon ayarları gibi veritabanı dışında duran dosyalar da olabilir. Hangilerinin yedek kapsamında olduğunu iş ortağınızla birlikte yazılı bir listeye dökün.

SQL Server’da üç temel yedek türü vardır:

Yedek türü	Ne içerir?	Ne zaman işe yarar?
Tam yedek (full)	Veritabanının yedeğin bittiği andaki tamamı	Her geri dönüşün başlangıç noktasıdır
Fark yedeği (differential)	Son tam yedekten bu yana değişen veri	Tam yedekler arasında daha sık nokta sağlar
İşlem günlüğü yedeği (log)	Henüz yedeklenmemiş işlem kayıtları	Gün içinde belirli bir ana dönmeyi sağlar; tam kurtarma modeli ve önceden alınmış bir tam yedek gerektirir

Yedeğiniz gerçekten alınıyor mu? Beş dakikalık kontrol

BT sorumlunuza veya iş ortağınıza şu dört soruyu sorun. Cevaplar net değilse, yedeğiniz de net değildir.

1. Ne zaman? Yedek hangi gün ve saatte alınıyor? Son başarılı yedek ne zaman bitti?
2. Nereye? Yedek dosyaları hangi klasörde, hangi diskte duruyor? Sunucunun dışında bir kopya var mı?
3. Ne kadar süre? Eski yedekler kaç gün saklanıyor?
4. Kim? Yedek hata verdiğinde kim haberdar oluyor?

Son yedeğin tarihi tahminle değil, kayıtla öğrenilir. SQL Server aldığı yedeklerin geçmişini msdb veritabanında tutar. BT sorumlunuz şu sorguyla son yedekleri listeleyebilir: SELECT database_name, type, backup_finish_date FROM msdb.dbo.backupset ORDER BY backup_finish_date DESC; Sonuçtaki type sütununda D tam yedeği, I fark yedeğini, L işlem günlüğü yedeğini gösterir.

Logo kurulumunuz ücretsiz SQL Server Express sürümündeyse bir noktaya ayrıca dikkat edin. Microsoft’un belgesine göre Express sürümünde SQL Server Agent yoktur. Bu yüzden zamanlanmış yedek genellikle Windows Görev Zamanlayıcı ile çalışan bir betikle alınır. Microsoft, görevin “başarılı” görünmesinin yedeğin alındığını kanıtlamadığını belirtir. Klasörde yeni dosyaların oluştuğunu ve yedek geçmişinde yeni satırlar olduğunu düzenli kontrol edin.

Logo yedekleme planı: ne zaman, nereye, kaç kopya?

Plan, işletmenizin kaldırabileceği kayıpla başlar. Kendinize şunu sorun: bir günlük fatura, irsaliye ve fiş girişini yeniden yapabilir misiniz? Cevap hayırsa gece alınan tek bir tam yedek size yetmez. Tam yedeğin yanında gün içinde fark veya işlem günlüğü yedekleri planlanmalıdır.

• Ayrı yer: Microsoft’un yedekleme ve geri yükleme rehberi, yedeklerin veritabanı dosyalarından ayrı bir fiziksel yerde veya cihazda tutulmasını önerir. Aynı diskteki yedek, disk bozulduğunda veriyle birlikte kaybolur.
• Ağdan ayrı bir kopya: Fidye yazılımları ağdan erişilebilen yedekleri de şifreleyebilir. En az bir kopyanın sürekli erişilebilir olmayan bir yerde durması bu riski azaltır. Felaket senaryolarını felaket kurtarma planı yazımızda ele aldık.
• Şifreleme ve yetki: Logo yedeği cari, çalışan ve banka bilgileri gibi kişisel veriler içerir. Microsoft, yedekleri şifrelemeyi ve yedek alan hesaplara gerekenden fazla yetki vermemeyi önerir.
• Saklama süresi: Kaç günlük yedek saklayacağınızı belirleyin. Dönem sonu öncesi alınan yedeği ayrıca ve daha uzun saklayın.
• Yazılı kayıt: Yedeklerin yeri, sorumlusu ve son testte geri yüklemenin ne kadar sürdüğü tek bir belgede dursun.

Yedek planını SQL Server tarafında kurmak veya gözden geçirmek için destek gerekiyorsa SQL danışmanlığı sayfamıza göz atabilirsiniz.

Geri dönüş testi adım adım

Microsoft’un rehberindeki ilke açıktır: yedeklerinizi test etmeden bir geri yükleme stratejiniz yoktur. Test, yedeğin bir kopyasının ayrı bir sisteme geri yüklenmesiyle yapılır. Logo kullanan bir işletmede adımlar şöyledir:

1. Test yerini hazırlayın. Canlı sistemden ayrı bir sunucu veya ayrı bir SQL Server örneği kullanın. Testi asla canlı veritabanının üzerine yapmayın.
2. Son yedeği seçin. En yeni tam yedeği ve varsa sonrasındaki fark ve günlük yedeklerini alın. Testi zaman zaman sunucu dışındaki kopyadan yapın; o kopyanın da açıldığını görün.
3. Farklı bir adla geri yükleyin. Geri yüklemenin hata vermeden bittiğini kontrol edin.
4. Tutarlılığı kontrol edin. Microsoft, geri yüklemeden sonra DBCC CHECKDB çalıştırılmasını önerir. Bu komut, veritabanında bozulma olup olmadığını gösterir. BT sorumlunuz veya iş ortağınız çalıştırır.
5. İş verisini karşılaştırın. Logo uygulamasını test veritabanına bağlamak kurulum ve lisans ayarı gerektirir; bu adımı iş ortağınızla planlayın. Sonra yedeğin alındığı anla karşılaştırın: son kesilen faturanın numarası ve tarihi, birkaç cari hesabın bakiyesi, birkaç malzemenin stok miktarı ve mizan toplamları tutuyor mu?
6. Süreyi ölçün ve kaydedin. Geri yüklemenin başladığı ve bittiği saati yazın. Bu süre, gerçek bir arızada sistemin ne kadar kapalı kalacağının en iyi göstergesidir. Tarih, yedek dosyası, süre, sonuç ve kontrol eden kişiyi kayda geçirin.
7. Test ortamını temizleyin. Test veritabanı gerçek kişisel veri içerir. İşiniz bitince silin ya da canlı sistem kadar sıkı koruyun.

Projelerimizde önerdiğimiz düzen, testi en az üç ayda bir ve her büyük değişiklikten önce yapmaktır. Sunucu yavaşlığı nedeniyle uzayan yedek ve geri yükleme sürelerini Logo veritabanı yavaşladı mı yazımızdaki kontrollerle birlikte değerlendirin.

Büyük işlemlerden önce elle yedek

Bazı işlemler geri alınması zor değişiklikler yapar. Bunlardan hemen önce, zamanlanmış yedeği beklemeden bir tam yedek alın ve dosyanın oluştuğunu kontrol edin:

• Logo sürüm geçişi veya güncellemesi
• Dönem devri ve yıl sonu işlemleri
• Toplu fiyat değişikliği, toplu kayıt silme veya veri aktarımı
• Yeni bir entegrasyonun canlıya alınması

Rutin yedek zincirini bozmamak için SQL Server’ın kopya amaçlı (COPY_ONLY) yedek seçeneği kullanılabilir. Bunu BT sorumlunuzla konuşun.

Sık yapılan hatalar

• Yedeğin aynı sunucuda durması: Sunucu arızasında veya fidye yazılımında yedek de gider.
• Program klasörünü yedek sanmak: Veriler SQL Server veritabanındadır, klasörde değil.
• “Başarılı” mesajına güvenmek: Dosyanın ve yedek geçmişinin kontrol edilmemesi.
• İlk geri yüklemeyi kriz günü yapmak: Süre ve adımlar bilinmediği için kapalı kalma uzar.
• Testi canlı veritabanı üzerinde yapmak: Güncel veri eski yedekle ezilebilir.
• Herkesin erişebildiği, şifresiz yedekler: Kişisel verinin yetkisiz kişilere ulaşma riski doğar.
• Bilgiyi tek kişide bırakmak: Yedeği bilen tek kişi izindeyken arıza çıkabilir.
• Kaynağı bilinmeyen yedek dosyası yüklemek: Microsoft, güvenilmeyen kaynaktan gelen yedeği geri yüklemenin tüm SQL Server ortamı için güvenlik riski olduğunu belirtir.

Logo yedekleme kontrol listesi

• Logo’ya ait veritabanları ve veritabanı dışındaki dosyalar yazılı olarak listelendi mi?
• Son başarılı yedeğin tarihi msdb geçmişinden kontrol edildi mi?
• Kabul edilebilir veri kaybına göre tam, fark ve günlük yedekleri planlandı mı?
• Yedeklerin bir kopyası sunucu dışında, bir kopyası ağdan ayrı mı?
• Yedekler şifreli ve erişim yalnızca yetkili kişilerde mi?
• Son geri dönüş testi ne zaman yapıldı, süresi ve sonucu kayıtlı mı?
• Testte DBCC CHECKDB çalıştırıldı ve iş verileri karşılaştırıldı mı?
• Büyük işlemlerden önce elle yedek alma kuralı herkesçe biliniyor mu?
• Yedek hatası olduğunda haber alan bir sorumlu var mı?

Özet

Logo yedekleme üç sorunun cevabıdır: yedek düzenli alınıyor mu, güvenli bir yerde duruyor mu ve gerçekten geri yüklenebiliyor mu? İlk ikisi için plan ve kontrol yeterlidir. Üçüncüsü ancak düzenli bir geri dönüş testiyle bilinir. Testi yapan ekip, arıza günü ne yapacağını ve ne kadar süreceğini önceden bilir.

ÇAP Teknoloji olarak Logo kurulumunuzun yedek planını gözden geçiriyor, ilk geri dönüş testini sizinle birlikte yapıyor ve sonucu belgeliyoruz. Ayrıntılar için ERP danışmanlığı sayfamıza göz atın ya da bizimle iletişime geçin.

Sıkça Sorulan Sorular