Yıl sonu devir işleminden önce yedek: kontrol listesi

Devir işlemi neden ayrı bir yedek gerektirir?

Devir işlemi, yıl sonunda cari, stok, kasa ve banka bakiyelerinin yeni döneme aktarılmasıdır. Logo, Netsis, Mikro, ETA ve Zirve gibi muhasebe programlarında “devir işlemi”, “yıl sonu devri” veya “sene sonu devir” adıyla geçer. İşlem çok sayıda kaydı tek seferde değiştirir; yarıda kalırsa ya da yanlış seçenekle çalıştırılırsa sonucu elle düzeltmek çoğu zaman mümkün olmaz.

Günlük otomatik yedeğiniz olsa bile devirden hemen önce ayrı bir yedek alın. Gece alınan yedek, o gün devirden önce girilen son kayıtları içermez. Devir öncesi yedek ise “devirden bir dakika önceki durum” olarak adıyla ayrılır ve aylar sonra arandığında kolayca bulunur.

Devir adımlarının kendisi programdan programa değişir; bunlar için program üreticinizin veya bayinizin yönergesini izleyin. Bu rehber işin yedek ve geri dönüş tarafını anlatır.

Başlamadan önce: programınız SQL Server kullanıyor mu?

Aynı muhasebe programının farklı sürümleri farklı veritabanı kullanabilir; bazı sürümlerde veri yazılım firmasının bulutunda tutulur ve veritabanına erişim verilmez. Aşağıdaki adımlar, veritabanı kendi bilgisayarınızda veya sunucunuzda SQL Server üzerinde duruyorsa geçerlidir.

SQL Server Management Studio (SSMS) ile sunucuya bağlanın ve şu sorguyu çalıştırın. Listede muhasebe programınızın veritabanını görüyorsanız devam edebilirsiniz. Emin değilseniz veritabanı adını bayinize sorun.

SELECT name, recovery_model_desc
FROM sys.databases
ORDER BY name;

1. Devirden önce bütün kullanıcıların programdan çıktığını doğrulayın.
2. Yedeğin yazılacağı diskte veritabanı boyutundan fazla boş alan olduğunu kontrol edin.
3. Yedek klasörüne SQL Server servisinin yazabildiğinden emin olun; yazamıyorsa yedek “erişim reddedildi” hatasıyla durur.
4. Devir için ayırdığınız saatte başka bir yedekleme veya bakım işinin çalışmadığını kontrol edin.

Logo, Netsis, Mikro, ETA ve Zirve’de neyi yedeklemelisiniz?

Muhasebe programları verilerini genellikle birden fazla veritabanına dağıtır: her firmanın ya da yılın verisi ayrı bir veritabanında, kullanıcı ve ortak tanımlar ise ayrı bir ortak veritabanında durur. Devirden önce yalnız şirket veritabanını yedeklemek yetmeyebilir; ortak veritabanı da aynı anda yedeklenmelidir. Aşağıdaki tablo ve sorgular, programınızın veritabanlarını SSMS listesinde tanımanıza yardım eder.

-- Netsis, Mikro ve ETA ortak veritabanlarını listeler
SELECT name, create_date
FROM sys.databases
WHERE name = N'NETSIS'
   OR name LIKE N'MikroDB%'
   OR name LIKE N'ETA[_]%'
ORDER BY name;

-- Bir veritabanının Logo veritabanı olup olmadığını kontrol eder
SELECT COUNT(*) AS logo_tablo_sayisi
FROM [VeritabaniAdi].INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE N'LG[_]%';

İkinci sorguda VeritabaniAdi yerine kontrol etmek istediğiniz veritabanının adını yazın; sonuç sıfırdan büyükse içinde Logo tabloları vardır. Veritabanı adları kurulumdan kuruluma değişebilir. Tablodaki kalıplar size yol göstermek içindir; emin olmadığınız veritabanını bayinize sorun.

Netsis’te olduğu gibi devir yeni yılın şirketine yapılıyorsa, devirle birlikte yeni bir veritabanı oluşur. Devirden sonra düzenli yedekleme planınızın bu yeni veritabanını da kapsadığını kontrol edin; eski plan yalnız geçen yılın veritabanını yedeklemeye devam ediyor olabilir.

ETA kullanıyorsanız yedeği programın kendi Veritabanı Yönetimi aracıyla (ETASQLMNG) da alabilirsiniz. Hangi yolla alırsanız alın, aşağıdaki doğrulama ve test adımları aynıdır.

Zirve’de ve Firebird ile kurulmuş Akınsoft WOLVOX’ta üreticinin önerdiği yöntem, servisi durdurup veri klasörünü kopyalamaktır. Servis çalışırken kopyalanan klasör bozuk ya da eksik çıkabilir; Akınsoft bunu açıkça uyarır. Bu yöntemde aşağıdaki SQL komutları yerine şu kuralları uygulayın: kopyayı devirden hemen önce alın, sunucunun dışına taşıyın ve açıldığını bayinizle birlikte ayrı bir bilgisayarda deneyin. Firebird veritabanını gbak aracıyla yedeklemek için Firebird gbak rehberine bakın. WOLVOX MS SQL Server ile kurulduysa DATABASE_FB klasörü sizin verinizi içermez; bu rehberdeki SQL adımlarını izleyin.

Luca gibi web tabanlı programlarda veriler üreticinin sunucularında tutulur; veritabanına doğrudan erişiminiz olmadığı için bu rehberdeki adımlar uygulanmaz. Devir öncesi güvence için üreticinin yönergesini izleyin.

Firebird gbak ile yedekleme rehberi → · Firebird otomatik bulut yedekleme →

1. adım: Devirden hemen önce tam yedek alın

Aşağıdaki komut veritabanının tam yedeğini alır. Veritabanı adını ve dosya yolunu kendi sisteminize göre değiştirin; dosya adına tarihi, saati ve “devir öncesi” ifadesini yazın.

BACKUP DATABASE [MuhasebeDB]
TO DISK = N'D:\Yedek\MuhasebeDB_devir_oncesi_2026-12-31_1430.bak'
WITH COPY_ONLY, CHECKSUM,
     NAME = N'Devir oncesi tam yedek';

COPY_ONLY, bu yedeğin mevcut yedekleme düzeninizi etkilememesini sağlar; düzenli fark yedeği alan bir planınız varsa sırası bozulmaz. CHECKSUM, yedek yazılırken sayfaların sağlamasını denetler ve sonraki doğrulama adımını anlamlı kılar. Komutta INIT kullanılmaz: aynı ad yanlışlıkla tekrar verilse bile var olan yedek silinmez.

Komut bittiğinde “BACKUP DATABASE successfully processed … pages” satırını görmelisiniz. Hata mesajı çıkarsa devir işlemine başlamayın.

Bu dosya, devirden önceki sağlam durumdur; ona bir daha dokunmayın. Devir yarıda kalır ve listeye baştan dönerseniz yeni yedeği mutlaka yeni bir dosya adıyla alın (örneğin saati değiştirerek _1655). Aynı adı kullanmak, sorunlu durumun yedeğini sağlam kopyayla karıştırmanıza yol açabilir.

2. adım: Yedek dosyasının okunabildiğini doğrulayın

Yedek dosyasının oluşması, içeriğinin sağlam olduğunu göstermez. Şu komut dosyayı baştan sona okur ve sağlamaları denetler; veritabanınıza dokunmaz.

RESTORE VERIFYONLY
FROM DISK = N'D:\Yedek\MuhasebeDB_devir_oncesi_2026-12-31_1430.bak'
WITH CHECKSUM;

Beklenen sonuç “The backup set on file 1 is valid.” satırıdır. Bu kontrol dosyanın eksiksiz ve okunabilir olduğunu söyler; içindeki verinin mantıksal olarak tutarlı olduğunu kanıtlamaz. Onun için bir sonraki adım gerekir.

3. adım: Test veritabanına geri yükleyip bütünlüğü kontrol edin

Yedeğin gerçekten işe yaradığını görmenin yolu, onu canlı veritabanından ayrı bir adla geri yüklemektir. Önce yedeğin içindeki mantıksal dosya adlarını öğrenin; geri yükleme komutunda bunları kullanacaksınız.

RESTORE FILELISTONLY
FROM DISK = N'D:\Yedek\MuhasebeDB_devir_oncesi_2026-12-31_1430.bak';

RESTORE DATABASE [MuhasebeDB_Test]
FROM DISK = N'D:\Yedek\MuhasebeDB_devir_oncesi_2026-12-31_1430.bak'
WITH MOVE N'MuhasebeDB' TO N'D:\Test\MuhasebeDB_Test.mdf',
     MOVE N'MuhasebeDB_log' TO N'D:\Test\MuhasebeDB_Test_log.ldf',
     CHECKSUM, RECOVERY;

DBCC CHECKDB (N'MuhasebeDB_Test') WITH NO_INFOMSGS;

MOVE satırlarındaki ilk ad, FILELISTONLY çıktısındaki LogicalName sütunundan gelir; ikinci yol test dosyalarının yazılacağı yerdir.

DBCC CHECKDB hata bulmazsa NO_INFOMSGS seçeneğiyle hiçbir satır döndürmez; bu, 0 hata anlamına gelir. Ardından test veritabanında bildiğiniz bir tabloyu açın ve son kayıtların orada olduğunu gözle kontrol edin. Kontrol bitince test veritabanını silebilirsiniz.

Geri yükleme testini düzenli hale getirmek için rehber →

4. adım: Yedeği sunucunun dışına kopyalayın

Yedek, veritabanıyla aynı diskte duruyorsa disk arızasında veya fidye yazılımında ikisi birlikte kaybedilir. Devir öncesi yedeğin bir kopyasını sunucudan ayrı bir yere alın: harici bir disk ve mümkünse bulut.

Bu yedeği en az yeni dönemin ilk ay kapanışı sorunsuz tamamlanana kadar saklayın. Devir sırasındaki bir hata bazen haftalar sonra, ilk mizan veya ilk beyanname hazırlanırken fark edilir. Düzenli yedeklerinizin saklama süresi bu aralıktan kısaysa devir öncesi yedeği ayrıca koruyun.

Devirden sonra sorun çıkarsa nasıl geri dönersiniz?

Bakiyeler tutmuyorsa veya devir yarıda kaldıysa ilk iş, zararı büyütmemektir.

Canlı veritabanını devir öncesi yedekten geri yüklemek, mevcut verinin üzerine yazan bir işlemdir. Bu kararı veritabanı yöneticiniz veya program bayinizle birlikte verin. Geri yüklemeden önce bozuk hâliyle mevcut veritabanının da yedeğini alın; sorunun nedenini sonradan incelemek için gerekebilir.

1. Kullanıcıları programdan çıkarın ve yeni kayıt girişini durdurun.
2. Sorunun ne olduğunu ve ne zaman fark edildiğini yazın; ekran görüntüsü alın.
3. Mevcut (sorunlu) veritabanının ayrı bir yedeğini alın.
4. Devir öncesi yedeği önce test adıyla geri yükleyip doğru yedek olduğunu kontrol edin.
5. Canlıya geri yüklemeyi yetkili kişiyle birlikte yapın; ardından deviri yönergeye göre yeniden çalıştırın.

Kladim bu kontrol listesinin neresinde durur?

Kladim Agent, SQL Server veritabanınızı her gün otomatik olarak yedekler, yedeği bilgisayarınızdan çıkmadan şifreler ve Türkiye’deki sunuculara aktarır. Devirden hemen önce Kladim’de yedeği elle de başlatabilirsiniz; böylece devir öncesi durumun sunucu dışında bir kopyası oluşur (4. adım).

Restore Proof, etkin kapsamda SQL Server yedeğinizi ayrı bir test ortamına geri yükler ve DBCC CHECKDB ile kontrol eder; yani 3. adımı düzenli olarak sizin yerinize yapar ve sonucu raporlar. Sonuç yalnız test edilen yedeği kapsar, kurtarma garantisi değildir.

Kladim deviri sizin yerinize yapmaz ve canlı muhasebe veritabanına geri yükleme standart pakete dahil değildir; bu işlem veritabanı yöneticinizin veya bayinizin sorumluluğundadır. Kladim’i 100 GB alanla 15 gün ücretsiz deneyebilirsiniz.

SQL Server bulut yedekleme programını inceleyin → · Restore Proof kapsamı →

Teknik kaynaklar

• Microsoft Learn: BACKUP (Transact-SQL)
• Microsoft Learn: Copy-only backups
• Microsoft Learn: RESTORE VERIFYONLY
• Microsoft Learn: RESTORE (Transact-SQL)
• Microsoft Learn: DBCC CHECKDB
• ETA: Kullanıcı parametre ve tanımların kopyalanması (yedek uyarısı)
• Zirve Blog: Zirve programlarında yedekleme nasıl yapılır?
• AKINSOFT Bilgi Bankası: Firebird veri tabanlı programlarda yedek alma
• AKINSOFT Bilgi Bankası: WOLVOX ERP’de veritabanı transferi (Firebird ve MS SQL Server)

Motorun geri yükleme ayrıntıları için kullandığınız sürümün resmî belgesini esas alın.