KOBİ'ler için sunucu bakımı: neler yapılmalı, kesinti neye mal olur?

Kısa cevap: Bir KOBİ sunucusunun bakımı; güvenlik güncellemelerinin zamanında uygulanmasını, yedeklerin alınmasını ve düzenli olarak geri yüklenerek denenmesini, sunucunun durumunun sürekli izlenmesini, sertifikaların ve erişim yetkilerinin yönetilmesini, log kayıtlarının incelenmesini ve tüm bunların yazılı olarak belgelenmesini kapsar. Bu işlerin her biri tek başına küçüktür; ama biri aksadığında e-posta, dosya paylaşımı, muhasebe ve ERP aynı anda durabilir. Bakımın değeri de burada ortaya çıkar: Bir kesintinin maliyetini kendi rakamlarınızla hesapladığınızda, düzenli bakımın neden bir gider değil bir risk yönetimi aracı olduğu netleşir.

KOBİ sunucularında bakım neden aksar?

Büyük kurumlarda sunucuların sorumlusu bellidir. Küçük ve orta ölçekli işletmelerde ise sunucu çoğu zaman bir dolabın içinde ya da bir bulut hesabında sessizce çalışır; bakım, "bilgisayardan en iyi anlayan" çalışanın asıl işinin arasına sıkıştırılır. Bu sunucuda genellikle işletmenin en kritik verileri durur: ortak klasörler, muhasebe veritabanı, ERP, e-posta arşivi ve e-Belge kopyaları. Aksaklıklar da çoğunlukla sinsice birikir: Kimsenin bakmadığı bir uyarı e-postası, aylar önce dolmaya başlamış bir disk ya da bir yazılım güncellemesinden sonra sessizce durmuş bir yedekleme işi. Bakımın amacı, bu küçük işaretleri bir kesintiye dönüşmeden yakalamaktır.

Sunucu bakımı neleri kapsar? Yedi düzenli iş

1. Güncelleme ve yama yönetimi

İşletim sistemi, veritabanı, web sunucusu ve uygulamalar için yayımlanan güvenlik güncellemeleri, bilinen ve kamuya açık hâle gelmiş açıkları kapatır. Kritik güvenlik yamaları gecikmeden, işlevsel güncellemeler ise önceden duyurulan bakım pencerelerinde ve mümkünse önce bir test ortamında uygulanmalıdır. Kişisel Verileri Koruma Kurumu'nun Kişisel Veri Güvenliği Rehberi de kullanılmayan yazılım ve servisleri güncel tutmaya çalışmak yerine kaldırmanın, açıkları azaltmanın kolay bir yolu olduğunu hatırlatır.

2. Yedekleme: 3-2-1 kuralı

Yaygın kabul gören 3-2-1 kuralına göre verinin en az üç kopyası bulunur, bu kopyalar en az iki farklı depolama ortamında tutulur ve bunlardan biri işletmenin dışında, başka bir konumda saklanır. KVKK'nın rehberi buna iki önemli ekleme yapar: Yedeklenen kişisel verilere yalnız sistem yöneticisi erişebilmeli ve veri seti yedekleri mutlaka ağ dışında tutulmalıdır. Aksi hâlde dosyaları şifreleyip fidye isteyen bir zararlı yazılım, ana sistemle birlikte yedekleri de kullanılamaz hâle getirebilir. Yedekleri şifrelemek ve fiziksel güvenliğini sağlamak da bu işin parçasıdır.

Türkiye'ye özgü bir ayrıntı daha var: e-Fatura ve e-Arşiv gibi e-Belgelerin muhafazası Türkiye sınırları içinde yapılmak zorunda; yurt dışında ise yalnız ikincil arşiv tutulabiliyor. Yedekleme planınızda e-Belge arşivinin birincil kopyasının nerede durduğunu ayrıca belirtin. Ayrıntılar için e-Fatura ve e-Arşiv rehberimize bakabilirsiniz.

3. Geri yükleme testi

Bir yedeğin işe yarayıp yaramadığı ancak geri yüklendiğinde anlaşılır. Bu yüzden bakım planında, belirli aralıklarla ve kayıt altına alınarak yapılan geri yükleme testleri bulunmalıdır: tek bir dosyanın, bir veritabanının ve gerektiğinde tüm sunucunun geri getirilmesi. Test aynı zamanda iki kritik soruyu cevaplar: Kesintiden sonra sistemi ne kadar sürede ayağa kaldırabiliyoruz ve en fazla ne kadarlık veri kaybını göze alabiliyoruz? Bu iki hedef, sırasıyla RTO (kurtarma süresi hedefi) ve RPO (kurtarma noktası hedefi) olarak adlandırılır ve yedekleme sıklığını doğrudan belirler.

4. İzleme ve alarm

İzlenen bir sunucu, sorun kullanıcıya yansımadan haber verir. Asgari olarak disk doluluğu, işlemci ve bellek kullanımı, kritik servislerin durumu, yedekleme işlerinin sonucu, disk ve RAID sağlığı, kesintisiz güç kaynağı ve sertifika bitiş tarihleri izlenmelidir. Alarmlar, sorunu çözecek kişiye gitmelidir; en iyi senaryoda kullanıcılar bir sorunun yaşandığını hiç fark etmez.

5. Sertifika ve alan adı yönetimi

Web siteleri, e-posta sunucuları ve uygulamalar TLS sertifikalarıyla çalışır; süresi dolan bir sertifika, sistem ayakta olsa bile hizmeti kullanılamaz hâle getirir. Bu konu önümüzdeki yıllarda daha da önem kazanıyor: CA/Browser Forum'un 2025'te kabul ettiği SC-081 kararıyla, genel TLS sertifikalarının azami geçerlilik süresi Mart 2026'dan itibaren kademeli olarak kısalıyor ve Mart 2029'da 47 güne iniyor. Bu takvimde sertifikaları elle yenilemek gerçekçi değil; yenilemenin otomatik yapılması ve izleme sisteminin bitiş tarihlerini takip etmesi gerekiyor. Alan adı yenileme tarihleri de aynı listede yer almalı.

6. Log kayıtları ve erişim denetimi

KVKK'nın rehberi, tüm kullanıcıların işlem hareketlerinin düzenli olarak kaydedilmesini, güvenlik yazılımı uyarılarının ve erişim kayıtlarının düzenli kontrol edilmesini, bilinen açıklara karşı zafiyet taraması ve sızma testi yapılmasını önerir. Erişim tarafında ise çalışanlara yalnız işleri için gereken yetkinin verilmesi, yönetici yetkisinin yalnız ihtiyaç anında kullanılması ve işten ayrılan çalışanların hesaplarının vakit kaybetmeden kapatılması beklenir. Uzaktan erişim ve yönetim panelleri için çok faktörlü kimlik doğrulama bugün temel bir gerekliliktir.

7. Dokümantasyon

Sunucuda hangi servislerin çalıştığı, nasıl yapılandırıldığı, hangi hesapların bulunduğu ve neyin ne zaman değiştirildiği yazılı olmalıdır. Dokümantasyonu olmayan bir sunucu, bakımı yapan kişiye bağımlı hâle gelir; o kişi izne çıktığında ya da hizmet sağlayıcı değiştiğinde risk büyür. Dokümantasyon ve tüm erişim bilgileri işletmeye ait olmalıdır.

Desteği biten yazılımı takvime koyun

Bakımın sık atlanan bir parçası da yazılımların yaşam döngüsüdür. Üreticinin güvenlik güncellemesi yayımlamayı bıraktığı bir işletim sistemi, ne kadar özenle bakılırsa bakılsın, bilinen açıklarla çalışmaya devam eder. Somut bir örnek: Microsoft'un yaşam döngüsü sayfasına göre Windows Server 2016 için genişletilmiş destek Ocak 2027'de sona eriyor. Bu sürümle çalışan bir sunucunuz varsa geçişi şimdiden planlamanız gerekir.

Aynı kontrolü Linux dağıtımları, veritabanı sürümleri ve web sunucusundaki yazılım bileşenleri için de yapın: Envanterdeki her bileşenin yanına destek bitiş tarihini yazın ve bu tarihleri yıllık bütçe planına taşıyın. Daha az bileşen, daha az bakım demektir; örneğin veritabanı ve sunucu taraflı eklenti gerektirmeyen statik bir web sitesinin güncellenecek parçası çok daha azdır. Bu yaklaşımı WordPress yerine kodla yazılmış web sitesi yazımızda ele aldık.

Kesinti neye mal olur? Kendi rakamlarınızla hesaplayın

İnternette dolaşan "bir saatlik kesintinin ortalama maliyeti" rakamları, başka ülkelerin ve çok farklı büyüklükteki şirketlerin verilerine dayanır; sizin işletmeniz için anlamlı değildir. Daha doğru yol, kesinti maliyetini kalem kalem kendi verinizle hesaplamaktır:

Bu tabloyu bir kez, gerçekçi bir senaryoyla doldurun: Örneğin "dosya sunucusu ve muhasebe bir iş günü boyunca çalışmıyor" ya da "fidye yazılımı nedeniyle son yedekten itibaren veriler kayboldu". Çıkan tutarı yıllık bakım bütçesiyle karşılaştırdığınızda, hangi yatırımın öncelikli olduğu kendiliğinden ortaya çıkar. Aynı hesap, hangi sistemlerin yedekli kurulması gerektiğini de gösterir; bu kararları sunucu altyapısı planlamasının parçası olarak ele alıyoruz.

KVKK açısından sunucu bakımı

6698 sayılı KVKK'nın 12. maddesi, veri sorumlusundan kişisel verilerin hukuka aykırı işlenmesini ve bunlara hukuka aykırı erişilmesini önlemek ve verilerin muhafazasını sağlamak için uygun güvenlik düzeyini temin edecek her türlü teknik ve idari tedbiri almasını ister. Kurum'un Kişisel Veri Güvenliği Rehberi'ndeki teknik tedbirler listesi, iyi bir sunucu bakım planıyla büyük ölçüde örtüşür: yetki matrisi ve yetki kontrolü, erişim logları, kullanıcı hesap yönetimi, ağ ve uygulama güvenliği, şifreleme, sızma testi, saldırı tespit ve önleme sistemleri, log kayıtları, yedekleme, güvenlik duvarı, güncel antivirüs sistemleri ve verilerin silinmesi, yok edilmesi veya anonim hâle getirilmesi.

Üç noktayı özellikle vurgulayalım. Birincisi, bakımı dışarıdan bir firmaya verdiğinizde sorumluluk ortadan kalkmaz; Kanun, verileri sizin adınıza işleyenlerle birlikte tedbirlerden müştereken sorumlu olduğunuzu açıkça söyler. Bu yüzden hizmet sözleşmesinde gizlilik, yetki ve veri güvenliği hükümleri bulunmalıdır. İkincisi, işlenen veriler kanuni olmayan yollarla başkalarının eline geçerse bu durumun en kısa sürede ilgili kişiye ve Kurul'a bildirilmesi gerekir; olay müdahale planınız kimin neyi yapacağını önceden tanımlamalıdır. Üçüncüsü, sunucu veya yedek yurt dışındaysa yurt dışına aktarım kuralları devreye girer; bu konuyu KVKK uyumlu web sitesi yazımızda ayrıca ele aldık. Barındırmayı Almanya'da Hetzner'in ISO/IEC 27001 sertifikalı veri merkezlerinde ya da talep hâlinde Türkiye'de yapıyoruz; hangi seçeneğin sizin için uygun olduğuna veri türüne göre birlikte karar veriyoruz.

Bakım sözleşmesinde nelere bakmalı?

• Yazılı müdahale süreleri: "En kısa sürede" yerine, arızanın önem derecesine göre saat olarak tanımlanmış süreler.
• İzleme dahil mi? İzleme ek bir seçenek değil, bakımın temel parçası olmalıdır.
• Yedek ve geri yükleme raporu: Yedeklerin alındığının ve geri yükleme testlerinin yapıldığının düzenli olarak raporlanması.
• Düzenli durum raporu: Güncelleme durumu, disk ve kapasite eğilimleri, uyarılar ve önerilen yatırımlar.
• Sınırların netliği: Barındırma firması donanımdan ve platformdan sorumludur; işletim sistemi, uygulamalar, yetkiler ve yedekler ise bakım sözleşmesinde açıkça tanımlanmalıdır.
• Dokümantasyon ve çıkış planı: Erişim bilgileri ve dokümantasyon size aittir; sözleşme sona erdiğinde nasıl devredileceği yazılı olmalıdır.
• KVKK hükümleri: Gizlilik, yetkilendirme, alt yüklenici kullanımı ve veri ihlali bildirimine ilişkin maddeler.

Kullanıcı bilgisayarları, yazıcılar ve ofis ağı gibi sunucu dışındaki ihtiyaçlar için IT destek hizmeti, sunucu bakımını tamamlayan ayrı bir başlıktır.

Sunucu bakımı kontrol listesi

• Tüm sunucuların, servislerin ve yazılım sürümlerinin envanterini çıkarın; her birine destek bitiş tarihini yazın.
• Kritik güvenlik güncellemelerinin uygulanma kuralını ve bakım penceresini belirleyin.
• 3-2-1 kuralına göre yedekleme kurun; bir kopyanın ağ dışında ve şifreli olduğundan emin olun.
• Her kritik sistem için RTO ve RPO hedefini yazın, geri yükleme testini takvime koyun ve sonuçları kaydedin.
• Disk, servis, yedek, donanım ve sertifika izlemesini kurun; alarmların doğru kişiye gittiğini test edin.
• Sertifika yenilemeyi otomatik hâle getirin; alan adı bitiş tarihlerini listeye ekleyin.
• Yetki matrisini gözden geçirin, ayrılan çalışanların hesaplarını kapatın, uzaktan erişimde çok faktörlü doğrulamayı açın.
• Log kayıtlarının tutulduğunu ve düzenli incelendiğini doğrulayın.
• e-Belge arşivinin birincil kopyasının Türkiye'de tutulduğunu kontrol edin.
• Kesinti maliyeti tablosunu bir senaryoyla doldurun ve sonucu bakım bütçesiyle karşılaştırın.

Sunucularınızın bugünkü durumunu, yedeklerinizi ve risklerinizi birlikte gözden geçirmek isterseniz sunucu bakımı hizmetimizin kapsamına göz atabilir, mevcut yapınızı bize anlatabilirsiniz.

Sık sorulan sorular

Kaynaklar

1. Kişisel Verileri Koruma Kurumu – Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler), Ocak 2018 (TÜRMOB arşiv kopyası) – erişim: Ekim 2026
2. 6698 sayılı Kişisel Verilerin Korunması Kanunu – güncel metin (mevzuat.gov.tr) – erişim: Ekim 2026
3. CA/Browser Forum – Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods – erişim: Ekim 2026
4. Microsoft Learn – Windows Server 2016 yaşam döngüsü – erişim: Ekim 2026
5. Backblaze – The 3-2-1 Backup Strategy – erişim: Ekim 2026
6. Vergi Usul Kanunu Genel Tebliği (Sıra No: 509) – muhafaza ve ibraz yükümlülüğü, güncel metin (mevzuat.gov.tr) – erişim: Ekim 2026

Bu yazı genel bilgilendirme amaçlıdır; hukuki, mali veya vergisel danışmanlık yerine geçmez. Mevzuat ve rakamlar yayın tarihindeki durumu yansıtır.