Sunucu yedekleme hizmeti Logo ve Mikro için: SQL Server veritabanı yedeği, Türkiye'de saklama ve geri yükleme testi

Logo, Mikro ya da Netsis kullanan bir işletmede kaybedilmesi en pahalı şey programın kendisi değildir, SQL Server veritabanıdır. Bu nedenle sunucu yedekleme hizmeti seçerken önce verinin nerede durduğunu, hangi yedek türünün ne işe yaradığını ve yedeğin gerçekten açılıp açılmadığını bilmek gerekir. Yazı, ERP sunucusundan sorumlu KOBİ sahibi, muhasebe sorumlusu ya da sistem yöneticisi için hazırlandı. Sonunda kendi yedeğinizi kurabilir ya da bir hizmeti doğru ölçütlerle değerlendirebilirsiniz.

Logo ve Mikro verisi nerede durur?

Bu programların hepsi veriyi Microsoft SQL Server üzerinde tutar. Yedeklenmesi gereken üç katman vardır:

1. SQL Server veritabanları. Firma, dönem, cari, stok ve fiş kayıtlarının tamamı buradadır. Logo'da firma veritabanının adı kurulumda verilir. Mikro'da genellikle bir ana veritabanı ve her firma için ayrı veritabanı bulunur. Netsis'te de firma veritabanlarına ek olarak sistem veritabanı vardır. Adları tahmin etmek yerine sunucuda listeleyin.
2. Program klasörü ve ek dosyalar. Rapor ve form tasarımları, kullanıcı ayarları, e-fatura ve e-defter çıktıları, dışa aktarılmış belgeler. Bunlar veritabanında olmayabilir.
3. Lisans ve yapılandırma. Lisans bilgisi çoğunlukla bayi ya da üretici üzerinden yeniden etkinleştirilir. Yedekten dönmek yerine lisans numaranızı ve bayi iletişim bilgisini ayrı bir yerde kayıtlı tutun.

Sunucudaki veritabanlarını, boyutlarını ve kurtarma modelini görmek için SQL Server Management Studio ya da sqlcmd ile şu sorguyu çalıştırın. SQL Server 2012 ve sonrası için hazırlandı, yalnızca okuma yapar.

-- Veritabanlarını, boyutlarını ve kurtarma modelini listeler
SELECT d.name AS veritabani,
       d.recovery_model_desc AS kurtarma_modeli,
       d.log_reuse_wait_desc AS log_bekleme_nedeni,
       CAST(SUM(CASE WHEN f.type = 0 THEN f.size END) * 8.0 / 1024 AS decimal(10,1)) AS veri_mb,
       CAST(SUM(CASE WHEN f.type = 1 THEN f.size END) * 8.0 / 1024 AS decimal(10,1)) AS log_mb
FROM sys.databases d
JOIN sys.master_files f ON f.database_id = d.database_id
GROUP BY d.name, d.recovery_model_desc, d.log_reuse_wait_desc
ORDER BY veri_mb DESC;

Beklenen çıktı, her veritabanı için bir satırdır. log_mb değeri veri_mb değerinden büyükse ve kurtarma modeli FULL ise log yedeği alınmıyor demektir. Bu konuya sık hatalar bölümünde döneceğiz.

İmaj yedeği mi, SQL .bak yedeği mi, ikisi birden mi?

İki yöntem farklı sorunları çözer. Karar verirken neyi geri getirmek istediğinize bakın.

Pratik öneri şudur: Veritabanı için her gün en az bir SQL .bak yedeği, sunucu için düzenli bir imaj yedeği. İmaj yedeği "sunucu yandı" senaryosunu, .bak yedeği "birisi yanlış fiş sildi" ya da "fidye yazılımı veritabanını şifreledi" senaryosunu kapsar. İkisinden birini seçmek zorundaysanız .bak yedeğini seçin: Windows ve programı yeniden kurmak saatler sürer, kaybolan muhasebe verisi geri gelmez.

Gün içinde çok fiş kesiliyorsa, kurtarma modelini FULL yapıp 15 ya da 30 dakikada bir log yedeği almak kaybı dakikalara indirir. Express sürümünde de log yedeği alınabilir, sadece zamanlamayı siz kurarsınız.

SQL Express'te Agent olmadan zamanlanmış yedek

SQL Server Express sürümünde SQL Server Agent yoktur, bu yüzden bakım planı kurulamaz. Çözüm, yedeği bir T-SQL dosyasıyla tanımlayıp Windows Görev Zamanlayıcı ile sqlcmd üzerinden çalıştırmaktır. Veritabanınız Express sınırına yaklaşıyorsa önce SQL Express 10 GB sınırı ve sürüm seçimi yazısına göz atın.

1. Yedek klasörü ve izinler

Yedeği SQL Server servis hesabı yazar, görevi çalıştıran kullanıcı değil. Örneğin D:\SQLYedek klasörünü oluşturun ve servis hesabına (varsayılan Express kurulumunda NT Service\MSSQL$SQLEXPRESS) yazma izni verin. Bu klasör veritabanı dosyalarının bulunduğu diskte olmamalı; mümkünse ayrı bir disk kullanın.

2. Yedek betiği (T-SQL)

Aşağıdaki betik tempdb dışındaki tüm çevrimiçi veritabanlarının tam yedeğini, tarih saat damgalı ayrı dosyalara alır. CHECKSUM seçeneği sayfa bozulmasını yedek sırasında yakalar. SQL Server 2012 ve sonrası, Express dahil tüm sürümler için hazırlandı. Dosyayı C:\YedekBetik\yedek.sql olarak kaydedin. Geri almak için dosyayı silmeniz yeterlidir, veritabanında kalıcı bir değişiklik yapmaz.

-- C:\YedekBetik\yedek.sql
-- tempdb dışındaki çevrimiçi veritabanlarını tam yedekler
SET NOCOUNT ON;
DECLARE @klasor nvarchar(260) = N'D:\SQLYedek\';   -- ORNEK_YEDEK_KLASORU, sonunda \ olmalı
DECLARE @tarih  nvarchar(20)  = FORMAT(GETDATE(), 'yyyyMMdd_HHmm');
DECLARE @ad sysname, @sql nvarchar(max);

DECLARE c CURSOR LOCAL FAST_FORWARD FOR
    SELECT name FROM sys.databases
    WHERE name <> N'tempdb' AND state_desc = N'ONLINE';

OPEN c;
FETCH NEXT FROM c INTO @ad;
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @sql = N'BACKUP DATABASE ' + QUOTENAME(@ad)
             + N' TO DISK = N''' + @klasor + @ad + N'_' + @tarih + N'.bak'''
             + N' WITH CHECKSUM, INIT;';
    PRINT @sql;
    EXEC sys.sp_executesql @sql;   -- hata olursa sqlcmd -b ile görev başarısız döner
    FETCH NEXT FROM c INTO @ad;
END
CLOSE c;
DEALLOCATE c;

Standard ya da Enterprise kullanıyorsanız WITH CHECKSUM, INIT kısmına COMPRESSION ekleyerek dosya boyutunu belirgin biçimde küçültebilirsiniz. Express bu seçeneği desteklemez.

3. Çalıştırma, kopyalama ve zamanlama (PowerShell)

Bu PowerShell betiği üç iş yapar: sqlcmd ile yedeği alır, yedekleri robocopy ile sunucu dışındaki bir paylaşıma kopyalar ve yerelde belirlenen günden eski .bak dosyalarını yalnızca yedek klasöründen siler. Son bölüm her gece 23:30'da çalışan bir zamanlanmış görev oluşturur; -Force ile tekrar çalıştırıldığında görevi günceller. Windows Server 2019, 2022 ve 2025 ile PowerShell 5.1 için hazırlandı; sqlcmd'nin kurulu olması gerekir.

Görevi ORNEK_YEDEK_KULLANICI gibi ayrı bir Windows hesabıyla çalıştırın. Bu hesabın SQL Server'da yedek alma yetkisi (her veritabanında db_backupoperator ya da sunucu düzeyinde uygun rol) ve hedef paylaşıma yazma izni olmalıdır. Geri almak için Unregister-ScheduledTask -TaskName "ERP-SQL-Yedek" -Confirm:$false komutunu çalıştırıp C:\YedekBetik klasörünü kaldırın.

# C:\YedekBetik\yedek-calistir.ps1
# Değiştirmeniz gereken değerler:
$SqlInstance = ".\SQLEXPRESS"                 # ORNEK_SQL_ORNEGI
$YedekKlasor = "D:\SQLYedek"                  # yedek.sql içindeki klasörle aynı olmalı
$UzakHedef   = "\\192.0.2.10\erp-yedek"       # ORNEK_UZAK_PAYLASIM
$YerelGun    = 7                              # yerelde tutulacak gün sayısı
$Log         = "C:\YedekBetik\yedek_$(Get-Date -Format yyyyMMdd_HHmm).log"

# 1) Yedeği al; -b hata durumunda sıfırdan farklı çıkış kodu döndürür
& sqlcmd -S $SqlInstance -E -b -i "C:\YedekBetik\yedek.sql" -o $Log
if ($LASTEXITCODE -ne 0) {
    Add-Content $Log "HATA: sqlcmd çıkış kodu $LASTEXITCODE"
    exit 1
}

# 2) Sunucu dışı kopya; yalnız yeni ve değişen .bak dosyaları kopyalanır
robocopy $YedekKlasor $UzakHedef *.bak /R:3 /W:30 /NP /LOG+:$Log | Out-Null
if ($LASTEXITCODE -ge 8) {
    Add-Content $Log "HATA: robocopy çıkış kodu $LASTEXITCODE"
    exit 2
}

# 3) Yalnız yedek klasöründeki eski .bak dosyalarını temizle
Get-ChildItem -Path $YedekKlasor -Filter *.bak -File |
    Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$YerelGun) } |
    Remove-Item -Verbose 4>> $Log

exit 0

Zamanlanmış görevi bir kez, yönetici PowerShell penceresinde oluşturun:

# Görevi oluşturur ya da günceller (idempotent)
$Kimlik  = Get-Credential -UserName "ORNEK_ALAN\ORNEK_YEDEK_KULLANICI" -Message "Yedek görevi hesabı"
$Eylem   = New-ScheduledTaskAction -Execute "powershell.exe" `
           -Argument '-NoProfile -ExecutionPolicy Bypass -File "C:\YedekBetik\yedek-calistir.ps1"'
$Tetik   = New-ScheduledTaskTrigger -Daily -At "23:30"
$Ayar    = New-ScheduledTaskSettingsSet -StartWhenAvailable -ExecutionTimeLimit (New-TimeSpan -Hours 4)
Register-ScheduledTask -TaskName "ERP-SQL-Yedek" -Action $Eylem -Trigger $Tetik -Settings $Ayar `
    -User $Kimlik.UserName -Password $Kimlik.GetNetworkCredential().Password -RunLevel Highest -Force

Doğrulama

Görevi hemen tetikleyip sonucunu kontrol edin:

Start-ScheduledTask -TaskName "ERP-SQL-Yedek"
Start-Sleep -Seconds 60
Get-ScheduledTaskInfo -TaskName "ERP-SQL-Yedek" | Select-Object LastRunTime, LastTaskResult
Get-ChildItem D:\SQLYedek -Filter *.bak | Sort-Object LastWriteTime -Descending | Select-Object -First 5 Name, Length

LastTaskResult değeri 0 olmalı, her veritabanı için o güne ait bir .bak dosyası görünmeli ve aynı dosyalar uzak paylaşımda da bulunmalıdır. SQL tarafında son yedekleri msdb geçmişinden de görebilirsiniz:

SELECT database_name, MAX(backup_finish_date) AS son_tam_yedek
FROM msdb.dbo.backupset
WHERE type = 'D'
GROUP BY database_name
ORDER BY son_tam_yedek;

Listenin başında bir günden eski tarih varsa o veritabanı yedeklenmiyor demektir.

Sunucu dışı kopya: Türkiye'de saklama, şifreleme ve değiştirilemez yedek

Yedek yalnızca ERP sunucusunun yanında duruyorsa, sunucuyu ele geçiren fidye yazılımı yedeği de şifreler. Sunucu dışı kopyada üç şeye bakın:

• Konum. Muhasebe verisi kişisel veri içerir (cari unvan, TC kimlik numarası, çalışan bordrosu). Yedeğin Türkiye'deki bir veri merkezinde tutulması, yurt dışı aktarım yükümlülüklerini gündeme getirmez. Hizmet sağlayıcıdan verinin ve kopyalarının hangi şehirde durduğunu yazılı isteyin.
• Şifreleme. Aktarım sırasında TLS, saklarken şifreleme. Şifreleme anahtarını kim tutuyor, anahtarı kaybederseniz ne olur, bunu netleştirin.
• Değiştirilemezlik. Object lock ya da benzeri bir yöntemle belirli bir süre boyunca silinemeyen, üzerine yazılamayan kopya. Sunucudaki yönetici hesabı ele geçirilse bile bu kopyaya dokunulamamalı. Kendi altyapınızda kurmak isterseniz S3 yedekleme rehberindeki restic ve rclone adımları Windows'ta da uygulanabilir.

Yukarıdaki robocopy adımı bir paylaşıma kopyalar ama tek başına değiştirilemez bir kopya sağlamaz. Paylaşımın ERP sunucusundaki hesapla silinebildiği her senaryoda, ikinci ve kilitli bir kopya gerekir.

Sunucu yedekleme hizmeti seçerken bakılacaklar

Teklifleri yan yana koyduğunuzda fiyattan önce şu soruların yanıtını karşılaştırın:

• RPO (en fazla ne kadar veri kaybını kabul ediyorsunuz): Günde bir yedek, en kötü durumda bir günlük fişin yeniden girilmesi demektir. Yoğun fatura kesen bir işletme için bu fazla olabilir; saatlik log yedeği destekleniyor mu?
• RTO (ne kadar sürede tekrar çalışmalısınız): Yedeğin indirilip yeni sunucuya açılması kaç saat sürer? 100 GB'lık bir veritabanını internet üzerinden indirmek ile aynı veri merkezinde açmak çok farklıdır.
• Saklama süresi: Son 7 gün mü, 30 gün mü, aylık ve yıllık kopyalar da var mı? Yanlış bir toplu işlem haftalar sonra fark edilebilir. Saklama süresinin faturaya etkisini ayrıca hesaplayın.
• SQL farkındalığı: Hizmet .bak dosyasını mı topluyor, VSS ile uygulama tutarlı imaj mı alıyor, yoksa yalnızca disk görüntüsü mü? Çalışan veritabanının dosyalarını (mdf, ldf) düz dosya gibi kopyalamak güvenilir bir yedek değildir.
• Geri yükleme desteği: Felaket anında yedeği kim açacak? Sağlayıcı test ortamı veriyor mu, Logo ya da Mikro'yu açıp doğrulamaya yardım ediyor mu?
• Uyarı: Yedek başarısız olduğunda kime, nasıl haber gidiyor? Sessizce duran yedek, hiç olmayan yedekten daha tehlikelidir çünkü güven verir.
• Çıkış: Sözleşme bittiğinde yedeklerinizi standart bir biçimde (.bak, VHDX gibi) alabiliyor musunuz?

Geri yükleme testi: yedeği ayrı sunucuda açıp doğrulama

Açılmayan yedek yedek değildir. Ayda en az bir kez, canlı sunucuya dokunmadan ayrı bir test sunucusunda deneme yapın. Test sunucusundaki SQL Server sürümü canlıdakiyle aynı ya da daha yeni olmalıdır; yeni sürümde alınan yedek eski sürüme açılmaz.

1. Dosyanın okunabildiğini kontrol edin

-- Dosya adını ve yolu kendi yedeğinize göre değiştirin
RESTORE VERIFYONLY FROM DISK = N'E:\Test\ORNEK_FIRMA_DB_20261026_2330.bak' WITH CHECKSUM;
RESTORE FILELISTONLY FROM DISK = N'E:\Test\ORNEK_FIRMA_DB_20261026_2330.bak';

İlk komut "The backup set on file 1 is valid." benzeri bir ileti döndürmelidir. İkincisi, veri ve log dosyalarının mantıksal adlarını verir; bir sonraki adımda bu adları kullanacaksınız.

2. Ayrı adla geri yükleyin ve bütünlüğü denetleyin

RESTORE DATABASE [ORNEK_FIRMA_DB_TEST]
FROM DISK = N'E:\Test\ORNEK_FIRMA_DB_20261026_2330.bak'
WITH MOVE N'ORNEK_VERI_MANTIKSAL_AD' TO N'E:\TestVeri\ORNEK_FIRMA_DB_TEST.mdf',
     MOVE N'ORNEK_LOG_MANTIKSAL_AD'  TO N'E:\TestVeri\ORNEK_FIRMA_DB_TEST_log.ldf',
     CHECKSUM, STATS = 10;

DBCC CHECKDB (N'ORNEK_FIRMA_DB_TEST') WITH NO_INFOMSGS;

DBCC CHECKDB hiçbir çıktı vermeden tamamlanırsa bütünlük hatası yoktur. Test bittiğinde test veritabanını kaldırmak için yalnızca ORNEK_FIRMA_DB_TEST adlı kopyayı hedefleyin ve canlı veritabanıyla karıştırmadığınızdan emin olun.

3. Program üzerinden doğrulayın

Teknik olarak açılan veritabanı, programın açabildiği anlamına gelmez. Test sunucusuna aynı sürüm Logo, Mikro ya da Netsis istemcisini kurup bu veritabanına bağlayın ve şunlara bakın:

• Firma ve dönem listesi geliyor mu?
• Yedek saatinden hemen önce kesilmiş son fatura ya da fiş görünüyor mu?
• Bir cari ve bir stok kartının bakiyesi canlı sistemdeki o saatteki değerle uyuşuyor mu?
• Mizan raporu hatasız alınabiliyor mu?

Tablo düzeyinde hızlı bir karşılaştırma için şu sorguyu hem canlıda hem testte çalıştırıp en büyük tabloların satır sayılarını yan yana koyabilirsiniz:

SELECT TOP (15) t.name AS tablo, SUM(p.rows) AS satir
FROM sys.tables t
JOIN sys.partitions p ON p.object_id = t.object_id AND p.index_id IN (0,1)
GROUP BY t.name
ORDER BY satir DESC;

Test sonucunu, tarihini ve geri yüklemenin kaç dakika sürdüğünü bir yere yazın. Bu süre gerçek RTO'nuzdur.

Sık yapılan hatalar

• Yedeği aynı diske almak. Disk arızalandığında veritabanı da yedek de gider. Ayrı disk ve sunucu dışı kopya şarttır.
• Test edilmemiş yedek. Görev aylardır "başarılı" görünür ama dosya yanlış klasöre ya da sıfır bayt olarak yazılıyordur. msdb geçmişini ve dosya boyutlarını düzenli kontrol edin.
• Log dosyasının şişmesi. Kurtarma modeli FULL olup log yedeği alınmıyorsa .ldf dosyası diski doldurana kadar büyür. İlk sorgudaki log_bekleme_nedeni sütununda LOG_BACKUP görüyorsanız ya düzenli log yedeği planlayın ya da nokta zamanlı geri dönüşe ihtiyacınız yoksa SIMPLE modele geçin. Log dosyasını küçültmek, bu nedeni çözmeden tekrar büyür.
• Program klasörünü unutmak. Özel rapor tasarımları ve e-belge çıktıları veritabanında değilse, yalnız .bak yedeği bunları kurtarmaz.
• Sürüm uyumsuzluğu. Canlıda SQL Server sürümü yükseltildikten sonra eski sürümlü test ya da yedek sunucusu yedeği açamaz.
• Uyarısız yedek. Görev başarısız olduğunda kimse haberdar olmuyorsa, sorun ancak geri dönüş gerektiğinde ortaya çıkar.

Sık sorulan sorular

Logo'nun ya da Mikro'nun kendi yedekleme ekranı yeterli mi?

Programların kendi yedekleme araçları elle yedek almak için kullanışlıdır, ancak zamanlama, sunucu dışı kopya, değiştirilemezlik ve uyarı gibi konuları çoğunlukla çözmez. SQL Server düzeyinde otomatik yedek ve ayrı bir sunucu dışı kopya, programın aracına ek olarak kurulmalıdır.

Çalışan veritabanının mdf ve ldf dosyalarını kopyalasam olur mu?

Olmaz. SQL Server çalışırken bu dosyalar açık ve sürekli değişir; kopyalanan dosya tutarsız olabilir ve eklenemeyebilir. Yedek ya BACKUP DATABASE ile ya da VSS destekli, uygulama tutarlı bir imaj yedeğiyle alınmalıdır.

Ne sıklıkla yedek almalıyım?

Gün sonunda bir tam yedek çoğu küçük işletme için asgari düzeydir. Gün içinde çok sayıda fatura ve fiş kesiliyorsa, kabul edebileceğiniz veri kaybı süresine göre saatlik ya da daha sık log yedeği ekleyin.

Netsis için de aynı adımlar geçerli mi?

Evet. Netsis de SQL Server kullandığı için .bak yedeği, Express'te Görev Zamanlayıcı yöntemi ve geri yükleme testi aynı şekilde uygulanır. Firma veritabanlarına ek olarak sistem veritabanını da yedek listesinde gördüğünüzden emin olun.

Geri yükleme testini canlı sunucuda yapabilir miyim?

Ayrı adla geri yükleme teknik olarak mümkündür ama disk ve işlemci yükü kullanıcıları yavaşlatır ve yanlış veritabanının üzerine yazma riski vardır. Ayrı bir test sunucusu ya da kısa süreli bir bulut sunucu daha güvenli bir yoldur.

Bu işi hazır yapmak isterseniz

Yedek betiğini, sunucu dışı kopyayı ve düzenli geri yükleme testini kendiniz yönetmek istemiyorsanız, bulut yedekleme hizmetimiz program ve sunucu yedeğini kapsar. Logo'yu zaten bulutta çalıştırmayı düşünüyorsanız Logo sunucu seçeneğinde de yedek seçeneği bulunur. Teklif alırken yukarıdaki RPO, RTO, saklama süresi ve geri yükleme desteği sorularını sormanızı öneririz.

Sonuç

İyi bir ERP yedeği üç parçadan oluşur: SQL Server'ın kendisiyle alınan tutarlı .bak yedeği, sunucu dışında ve tercihen Türkiye'de duran, silinemeyen bir kopya ve düzenli yapılan geri yükleme testi. Bugün yapabileceğiniz en somut iş, msdb geçmişinde son yedek tarihlerine bakmak ve bu ay bir veritabanını test sunucusunda açıp Logo ya da Mikro ile doğrulamaktır.