Web uygulamalar\u0131, g\u00fcn\u00fcm\u00fcz dijital ekosisteminin temel ta\u015flar\u0131ndan biridir ve i\u015f s\u00fcreklili\u011fi i\u00e7in hayati \u00f6neme sahiptir. Kullan\u0131c\u0131 verileri, i\u015flem kay\u0131tlar\u0131, uygulama kodlar\u0131 ve yap\u0131land\u0131rma bilgileri gibi kritik veriler, bir web uygulamas\u0131n\u0131n kalbinde yer al\u0131r. Bu verilerin kayb\u0131, ciddi finansal kay\u0131plara, itibar zedelenmesine, yasal sorunlara ve operasyonel kesintilere yol a\u00e7abilir. \u0130\u015fte bu noktada, “\u00fcretim ortam\u0131 web uygulamalar\u0131 i\u00e7in yedekleme” konusu, sadece bir gereklilik de\u011fil, ayn\u0131 zamanda stratejik bir zorunluluk haline gelmektedir.<\/p>\n
Yedekleme, temel olarak, verilerin orijinal konumlar\u0131ndan ba\u011f\u0131ms\u0131z olarak bir kopyas\u0131n\u0131n olu\u015fturulmas\u0131 ve saklanmas\u0131 s\u00fcrecidir. Ancak \u00fcretim ortam\u0131 i\u00e7in bu tan\u0131m \u00e7ok daha derinle\u015fir. Bir web uygulamas\u0131n\u0131n \u00fcretim ortam\u0131nda yedekleme, olas\u0131 bir felaket (donan\u0131m ar\u0131zas\u0131, yaz\u0131l\u0131m hatas\u0131, siber sald\u0131r\u0131, insan hatas\u0131 veya do\u011fal afet) durumunda sistemin ve verilerin kurtar\u0131labilmesini sa\u011flayan bir sigorta poli\u00e7esidir. Yedekleme olmadan, veri kayb\u0131 kal\u0131c\u0131 olabilir ve bir i\u015fletmenin tamamen kapanmas\u0131na dahi neden olabilir.<\/p>\n
Yedekleme stratejileri, sadece veri kayb\u0131n\u0131 \u00f6nlemekle kalmaz, ayn\u0131 zamanda sistemin eski bir kararl\u0131 durumuna geri d\u00f6nd\u00fcr\u00fclmesini de m\u00fcmk\u00fcn k\u0131lar. \u00d6rne\u011fin, hatal\u0131 bir kod da\u011f\u0131t\u0131m\u0131 veya yanl\u0131\u015f bir veritaban\u0131 i\u015flemi, uygulaman\u0131n \u00e7\u00f6kmesine veya hatal\u0131 \u00e7al\u0131\u015fmas\u0131na neden olabilir. \u0130yi tan\u0131mlanm\u0131\u015f bir yedekleme ve kurtarma plan\u0131, bu t\u00fcr durumlarda h\u0131zl\u0131 bir \u015fekilde m\u00fcdahale ederek i\u015f s\u00fcreklili\u011fini sa\u011flar.<\/p>\n
Bir web uygulamas\u0131n\u0131n \u00fcretim ortam\u0131nda ba\u015far\u0131l\u0131 bir \u015fekilde yedeklenmesi i\u00e7in, hangi veri t\u00fcrlerinin yedeklenmesi gerekti\u011fini net bir \u015fekilde anlamak \u00f6nemlidir. Genellikle d\u00f6rt ana kategoriye ayr\u0131l\u0131rlar:<\/p>\n
Web uygulamas\u0131n\u0131n kaynak kodu, betikler, k\u00fct\u00fcphaneler ve di\u011fer y\u00fcr\u00fct\u00fclebilir dosyalar bu kategoriye girer. \u00c7o\u011fu modern geli\u015ftirme s\u00fcrecinde, kaynak kodu Git gibi bir s\u00fcr\u00fcm kontrol sisteminde (VCS) saklan\u0131r. Bu, kodun kendisi i\u00e7in zaten bir yedekleme mekanizmas\u0131 sa\u011flar. Ancak, da\u011f\u0131t\u0131lm\u0131\u015f uygulaman\u0131n kendisi (derlenmi\u015f halleri, ba\u011f\u0131ml\u0131l\u0131klar\u0131 ve \u00e7al\u0131\u015fma zaman\u0131 ortam\u0131) de yedekleme kapsam\u0131na al\u0131nmal\u0131d\u0131r.<\/p>\n
Yap\u0131land\u0131rma dosyalar\u0131 (\u00f6rne\u011fin, veritaban\u0131 ba\u011flant\u0131 dizeleri, API anahtarlar\u0131, sunucu ayarlar\u0131, Nginx\/Apache yap\u0131land\u0131rmalar\u0131, ortam de\u011fi\u015fkenleri), uygulaman\u0131n do\u011fru \u00e7al\u0131\u015fmas\u0131 i\u00e7in kritik \u00f6neme sahiptir. Bu dosyalar genellikle hassas bilgiler i\u00e7erir ve g\u00fcvenli bir \u015fekilde yedeklenmeli ve \u015fifrelenmelidir. S\u00fcr\u00fcm kontrol sistemleri bu dosyalar\u0131n y\u00f6netimi i\u00e7in de kullan\u0131labilir, ancak hassas verilerin do\u011frudan VCS’ye i\u015flenmemesi, bunun yerine g\u00fcvenli ortam de\u011fi\u015fkenleri veya gizli y\u00f6netim hizmetleri kullan\u0131lmas\u0131 \u00f6nerilir.<\/p>\n
Bir web uygulamas\u0131n\u0131n en kritik veri kayna\u011f\u0131 genellikle veritaban\u0131d\u0131r. Kullan\u0131c\u0131 profilleri, i\u015flem kay\u0131tlar\u0131, i\u00e7erik ve uygulaman\u0131n dinamik verilerinin \u00e7o\u011fu burada saklan\u0131r. Veritaban\u0131 yedeklemeleri, uygulaman\u0131n \u00e7al\u0131\u015f\u0131r durumda kalmas\u0131 i\u00e7in en y\u00fcksek \u00f6nceli\u011fe sahip olmal\u0131d\u0131r.<\/p>\n
* \u0130li\u015fkisel Veritabanlar\u0131 (PostgreSQL, MySQL, SQL Server):<\/strong> Genellikle Kullan\u0131c\u0131lar\u0131n web uygulamas\u0131na y\u00fckledi\u011fi resimler, videolar, belgeler veya di\u011fer dosyalar (\u00f6rne\u011fin, bir e-ticaret sitesindeki \u00fcr\u00fcn resimleri, bir sosyal medya platformundaki kullan\u0131c\u0131 foto\u011fraflar\u0131) genellikle veritaban\u0131nda de\u011fil, ayr\u0131 bir dosya depolama sisteminde (\u00f6rne\u011fin, Amazon S3, Azure Blob Storage, Google Cloud Storage veya yerel bir dosya sistemi) saklan\u0131r. Bu dosyalar, uygulaman\u0131n kullan\u0131c\u0131 deneyimi i\u00e7in hayati \u00f6neme sahiptir ve yedeklenmelidir.<\/p>\n Statik varl\u0131klar (CSS, JavaScript dosyalar\u0131, fontlar vb.) genellikle uygulama koduyla birlikte da\u011f\u0131t\u0131l\u0131r veya bir CDN \u00fczerinden sunulur. E\u011fer bu varl\u0131klar dinamik olarak olu\u015fturuluyor veya s\u0131k\u00e7a de\u011fi\u015fiyorsa, onlar\u0131n da yedekleme stratejisine dahil edilmesi gerekebilir.<\/p>\n Eri\u015fim g\u00fcnl\u00fckleri (access logs), uygulama g\u00fcnl\u00fckleri (application logs), hata g\u00fcnl\u00fckleri (error logs) ve sistem g\u00fcnl\u00fckleri (system logs), uygulaman\u0131n performans\u0131n\u0131 izlemek, hatalar\u0131 ay\u0131klamak, g\u00fcvenlik olaylar\u0131n\u0131 tespit etmek ve denetim (audit) gereksinimlerini kar\u015f\u0131lamak i\u00e7in \u00e7ok \u00f6nemlidir. Bu g\u00fcnl\u00fckler genellikle merkezi bir g\u00fcnl\u00fck y\u00f6netim sistemine (ELK Stack, Splunk, Datadog) g\u00f6nderilir, ancak orijinal kaynaklardaki dosyalar\u0131n da belirli bir s\u00fcre i\u00e7in yedeklenmesi faydal\u0131 olabilir, \u00f6zellikle yasal uyumluluk gereksinimleri varsa.<\/p>\n Farkl\u0131 yedekleme stratejileri, veri hacmi, kurtarma hedefleri ve depolama maliyetleri gibi fakt\u00f6rlere ba\u011fl\u0131 olarak tercih edilir.<\/p>\n T\u00fcm verilerin eksiksiz bir kopyas\u0131n\u0131n olu\u015fturuldu\u011fu y\u00f6ntemdir. En basit yedekleme t\u00fcr\u00fcd\u00fcr ve geri y\u00fcklemesi en h\u0131zl\u0131 olan\u0131d\u0131r, \u00e7\u00fcnk\u00fc tek bir yedekleme setinden t\u00fcm veriler geri y\u00fcklenebilir. Ancak, b\u00fcy\u00fck veri setleri i\u00e7in depolama alan\u0131 ve yedekleme s\u00fcresi a\u00e7\u0131s\u0131ndan maliyetli olabilir. Genellikle periyodik olarak (\u00f6rne\u011fin haftal\u0131k) yap\u0131l\u0131r ve di\u011fer yedekleme t\u00fcrlerinin temelini olu\u015fturur.<\/p>\n Son herhangi bir<\/em> yedeklemeden (tam veya art\u0131ml\u0131) bu yana de\u011fi\u015fen veya eklenen verileri yedekler. Depolama alan\u0131 ve yedekleme s\u00fcresi a\u00e7\u0131s\u0131ndan en verimli y\u00f6ntemdir. Ancak geri y\u00fckleme i\u015flemi karma\u015f\u0131kt\u0131r, \u00e7\u00fcnk\u00fc tam yedeklemenin yan\u0131 s\u0131ra, o tam yedeklemeden sonraki t\u00fcm art\u0131ml\u0131 yedeklemelerin s\u0131rayla geri y\u00fcklenmesi gerekir. Bu da RTO’yu (Kurtarma S\u00fcresi Hedefi) art\u0131rabilir.<\/p>\n Son tam<\/em> yedeklemeden bu yana de\u011fi\u015fen veya eklenen t\u00fcm verileri yedekler. Art\u0131ml\u0131 yedeklemeye g\u00f6re daha fazla depolama alan\u0131 kaplar ancak geri y\u00fcklemesi daha basittir: sadece son tam yedekleme ve son diferansiyel yedekleme geri y\u00fcklenmelidir. Bu, art\u0131ml\u0131 yedeklemeye g\u00f6re daha h\u0131zl\u0131 bir geri y\u00fckleme sa\u011flar.<\/p>\n \u00d6zellikle sanalla\u015ft\u0131r\u0131lm\u0131\u015f ortamlar (VMware, Hyper-V) ve bulut platformlar\u0131 (AWS EBS Snapshots, Azure Disk Snapshots) i\u00e7in yayg\u0131n bir y\u00f6ntemdir. Bir disk veya sanal makinenin belirli bir andaki durumunun kopyas\u0131n\u0131 olu\u015fturur. Dosya sistemi veya blok seviyesinde \u00e7al\u0131\u015f\u0131r. H\u0131zl\u0131 bir \u015fekilde olu\u015fturulabilir ve geri y\u00fcklenebilir. Ancak, uygulama tutarl\u0131l\u0131\u011f\u0131 (application-consistent) sa\u011flamak i\u00e7in genellikle veritabanlar\u0131 gibi uygulamalar\u0131n duraklat\u0131lmas\u0131 veya \u00f6zel entegrasyonlar gerektirebilir.<\/p>\n Yedekleme stratejisinin temelini, ne s\u0131kl\u0131kta yedekleme yap\u0131laca\u011f\u0131 ve yedeklerin ne kadar s\u00fcreyle saklanaca\u011f\u0131 belirler. Bu kararlar, i\u015fin gereksinimlerine g\u00f6re Kurtarma Noktas\u0131 Hedefi (RPO) ve Kurtarma S\u00fcresi Hedefi (RTO) ile do\u011frudan ili\u015fkilidir.<\/p>\n Bir felaket durumunda kaybedilebilecek maksimum veri miktar\u0131d\u0131r. \u00d6rne\u011fin, RPO 1 saat ise, en k\u00f6t\u00fc senaryoda 1 saatlik veri kayb\u0131n\u0131 kabul edilebilir olarak g\u00f6r\u00fcrs\u00fcn\u00fcz. Bu, yedekleme s\u0131kl\u0131\u011f\u0131n\u0131z\u0131 belirler; RPO ne kadar d\u00fc\u015f\u00fckse, yedeklemeler o kadar s\u0131k yap\u0131lmal\u0131d\u0131r (\u00f6rne\u011fin, her 15 dakikada bir veya s\u00fcrekli replikasyon).<\/p>\n Bir felaket durumunda sistemin ne kadar s\u00fcrede yeniden tamamen \u00e7al\u0131\u015f\u0131r duruma getirilmesi gerekti\u011fidir. \u00d6rne\u011fin, RTO 4 saat ise, sistemin 4 saat i\u00e7inde kurtar\u0131lmas\u0131 gerekir. RTO, yedekleme stratejisinin yan\u0131 s\u0131ra felaket kurtarma plan\u0131n\u0131z\u0131, depolama t\u00fcrlerinizi ve kurtarma prosed\u00fcrlerinizin otomasyon derecesini etkiler. D\u00fc\u015f\u00fck RTO, daha h\u0131zl\u0131 eri\u015filebilir yedeklemeler ve daha otomatize edilmi\u015f kurtarma s\u00fcre\u00e7leri gerektirir.<\/p>\n * G\u00fcnl\u00fck:<\/strong> \u00c7o\u011fu web uygulamas\u0131 i\u00e7in standart bir yakla\u015f\u0131md\u0131r. Genellikle geceleri, sistem y\u00fck\u00fcn\u00fcn d\u00fc\u015f\u00fck oldu\u011fu zamanlarda tam veya diferansiyel yedeklemeler yap\u0131l\u0131r. Yedeklemelerin ne kadar s\u00fcreyle saklanaca\u011f\u0131n\u0131 belirler. Bu, yasal uyumluluk (GDPR, HIPAA), denetim gereksinimleri ve i\u015f ihtiya\u00e7lar\u0131 do\u011frultusunda belirlenir. Yayg\u0131n bir yakla\u015f\u0131m, “3-2-1 kural\u0131” ile birlikte \u00e7e\u015fitli zaman dilimleri i\u00e7in yedekleri saklamakt\u0131r: Yedeklemelerin nerede sakland\u0131\u011f\u0131, bir felaket durumunda kurtar\u0131labilirli\u011fi do\u011frudan etkiler. Tek bir konumda saklanan yedekler, o konumun ba\u015f\u0131na gelen bir felaketle birlikte kaybolabilir.<\/p>\n Yedeklemelerin uygulaman\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 fiziksel konumda veya ayn\u0131 veri merkezinde saklanmas\u0131d\u0131r. H\u0131zl\u0131 kurtarma i\u00e7in idealdir ancak site \u00e7ap\u0131nda bir felakete (yang\u0131n, sel, elektrik kesintisi) kar\u015f\u0131 savunmas\u0131zd\u0131r. Yerel diskler, A\u011f Ekli Depolama (NAS) veya Depolama Alan A\u011f\u0131 (SAN) cihazlar\u0131 kullan\u0131labilir.<\/p>\n Yedeklemelerin uygulaman\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 konumdan fiziksel olarak uzak bir yerde veya bulut depolama hizmetlerinde (Amazon S3, Azure Blob Storage, Google Cloud Storage) saklanmas\u0131d\u0131r. Bu, site \u00e7ap\u0131nda felaketlere kar\u015f\u0131 koruma sa\u011flar ve felaket kurtarma stratejisinin temelini olu\u015fturur. Bulut depolama, genellikle maliyet etkin, \u00f6l\u00e7eklenebilir ve y\u00fcksek eri\u015filebilirli\u011fe sahiptir.<\/p>\n Yedeklemelerin farkl\u0131 co\u011frafi b\u00f6lgelerde (\u00f6rne\u011fin, ABD Do\u011fu ve AB Bat\u0131 b\u00f6lgeleri) saklanmas\u0131d\u0131r. Bu, b\u00f6lgesel felaketlere (deprem, b\u00fcy\u00fck \u00f6l\u00e7ekli elektrik kesintisi) kar\u015f\u0131 ek bir koruma katman\u0131 sa\u011flar. Bulut sa\u011flay\u0131c\u0131lar\u0131 genellikle bu t\u00fcr bir yedeklili\u011fi kolayca sunar.<\/p>\n Bu kural, kapsaml\u0131 bir yedekleme stratejisi i\u00e7in alt\u0131n standart olarak kabul edilir: Bu kural, veri kayb\u0131 riskini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r ve \u00e7e\u015fitli felaket senaryolar\u0131na kar\u015f\u0131 dayan\u0131kl\u0131l\u0131k sa\u011flar.<\/p>\n Piyasada, web uygulamalar\u0131n\u0131n farkl\u0131 bile\u015fenlerini yedeklemek i\u00e7in \u00e7ok say\u0131da ara\u00e7 ve teknoloji bulunmaktad\u0131r.<\/p>\n * * B\u00fcy\u00fck bulut sa\u011flay\u0131c\u0131lar\u0131 (AWS, Azure, Google Cloud), kendi ekosistemlerindeki kaynaklar i\u00e7in entegre yedekleme \u00e7\u00f6z\u00fcmleri sunar: Veeam, Acronis, Commvault gibi \u00fc\u00e7\u00fcnc\u00fc taraf yaz\u0131l\u0131mlar, karma\u015f\u0131k hibrit veya \u00e7oklu bulut ortamlar\u0131 i\u00e7in kapsaml\u0131 yedekleme ve felaket kurtarma yetenekleri sunar. Genellikle daha geli\u015fmi\u015f y\u00f6netim aray\u00fczleri, raporlama ve farkl\u0131 platformlar aras\u0131 entegrasyon yetenekleri sa\u011flarlar.<\/p>\n Yedekleme s\u00fcre\u00e7lerinin otomatikle\u015ftirilmesi hayati \u00f6neme sahiptir. Manuel yedeklemeler hataya a\u00e7\u0131kt\u0131r ve s\u00fcrd\u00fcr\u00fclebilir de\u011fildir. Etkili bir yedekleme stratejisi, sadece do\u011fru ara\u00e7lar\u0131 se\u00e7mekle kalmaz, ayn\u0131 zamanda bu ara\u00e7lar\u0131n do\u011fru \u015fekilde uygulanmas\u0131n\u0131 ve s\u00fcrekli olarak y\u00f6netilmesini gerektirir.<\/p>\n T\u00fcm yedekleme s\u00fcre\u00e7lerini otomatikle\u015ftirin. Manuel m\u00fcdahale gerektiren ad\u0131mlar\u0131 en aza indirin. Otomatikle\u015ftirilmi\u015f betikler, zamanlay\u0131c\u0131lar ve bulut hizmetleri bu konuda b\u00fcy\u00fck kolayl\u0131k sa\u011flar. Bu, insan hatas\u0131 riskini azalt\u0131r ve yedeklemelerin d\u00fczenli olarak yap\u0131lmas\u0131n\u0131 garanti eder.<\/p>\n Yedeklenen veriler, \u00f6zellikle hassas bilgiler i\u00e7eriyorsa, hem depolama s\u0131ras\u0131nda (at rest) hem de aktar\u0131m s\u0131ras\u0131nda (in transit) \u015fifrelenmelidir. AES-256 gibi g\u00fc\u00e7l\u00fc \u015fifreleme algoritmalar\u0131 kullan\u0131n. \u015eifreleme anahtarlar\u0131n\u0131 g\u00fcvenli bir \u015fekilde y\u00f6netin ve yedekleme verilerinden ayr\u0131 tutun.<\/p>\n Yedekleme i\u015flemlerinin ba\u015far\u0131yla tamamland\u0131\u011f\u0131ndan emin olmak i\u00e7in s\u00fcrekli izleme kurun. Ba\u015far\u0131s\u0131z yedeklemeler veya anormal durumlar i\u00e7in an\u0131nda uyar\u0131lar (e-posta, SMS, Slack bildirimleri) al\u0131n. Loglar\u0131 d\u00fczenli olarak g\u00f6zden ge\u00e7irin.<\/p>\n Bir yedeklemenin var olmas\u0131, onun \u00e7al\u0131\u015faca\u011f\u0131 anlam\u0131na gelmez. Yedeklemelerinizi d\u00fczenli olarak test edin. Bu, bir felaket durumunda verilerinizi ger\u00e7ekten geri y\u00fckleyebilece\u011finizi do\u011frular. Testler, tam bir geri y\u00fckleme tatbikat\u0131 (DR Drill) \u015feklinde veya belirli dosyalar\u0131n\/veritabanlar\u0131n\u0131n geri y\u00fcklenmesi \u015feklinde olabilir. Test s\u0131kl\u0131\u011f\u0131, RPO ve RTO hedeflerinize ba\u011fl\u0131 olmal\u0131d\u0131r.<\/p>\n Yedekleme ve geri y\u00fckleme prosed\u00fcrlerini ayr\u0131nt\u0131l\u0131 olarak belgeleyin. Bu belgeler, bir felaket durumunda veya ekip \u00fcyelerinin de\u011fi\u015fmesi durumunda hayati \u00f6neme sahiptir. Belgelendirme, hangi verilerin yedeklendi\u011fini, nerede sakland\u0131\u011f\u0131n\u0131, ne s\u0131kl\u0131kta yap\u0131ld\u0131\u011f\u0131n\u0131 ve nas\u0131l geri y\u00fcklenece\u011fini a\u00e7\u0131k\u00e7a belirtmelidir.<\/p>\n \u00d6zellikle veritaban\u0131 yedeklemelerinde veri tutarl\u0131l\u0131\u011f\u0131 kritik \u00f6neme sahiptir. Uygulama \u00e7al\u0131\u015f\u0131rken al\u0131nan yedeklemeler, tutars\u0131z verilere yol a\u00e7abilir. Bu nedenle, veritaban\u0131n\u0131 yedeklemeden \u00f6nce k\u0131sa bir s\u00fcre i\u00e7in dondurmak (quiesce) veya i\u015flem g\u00fcnl\u00fcklerini kullanarak Point-in-Time Recovery (PITR) yetene\u011fi sunan ara\u00e7lar\u0131 kullanmak \u00f6nemlidir.<\/p>\n Yedekleme sistemlerine eri\u015fimi s\u0131k\u0131 bir \u015fekilde kontrol edin. Sadece yetkili ki\u015filerin yedekleme verilerine eri\u015febildi\u011finden emin olun. Minimum ayr\u0131cal\u0131k ilkesini uygulay\u0131n. Yedekleme depolama alanlar\u0131 i\u00e7in ayr\u0131 kimlik do\u011frulama mekanizmalar\u0131 ve eri\u015fim politikalar\u0131 kullan\u0131n.<\/p>\n Yedekleme, depolama ve veri aktar\u0131m\u0131 maliyetleri zamanla artabilir. Saklama politikalar\u0131n\u0131z\u0131 d\u00fczenli olarak g\u00f6zden ge\u00e7irin ve gereksiz veya eski yedekleri silerek maliyetleri optimize edin. Bulut depolama katmanlar\u0131n\u0131 (\u00f6rne\u011fin, AWS S3 Standard, S3 Infrequent Access, S3 Glacier) ak\u0131ll\u0131ca kullanarak maliyetleri d\u00fc\u015f\u00fcrebilirsiniz.<\/p>\n GDPR, HIPAA, PCI DSS gibi yasal d\u00fczenlemeler ve end\u00fcstri standartlar\u0131, veri saklama, \u015fifreleme ve eri\u015fim kontrol\u00fc konusunda belirli gereksinimler getirebilir. Yedekleme stratejinizin bu uyumluluk gereksinimlerini kar\u015f\u0131lad\u0131\u011f\u0131ndan emin olun.<\/p>\n Yedekleme ve Felaket Kurtarma (DR) genellikle birbirinin yerine kullan\u0131lan terimler olsa da, asl\u0131nda farkl\u0131 kavramlard\u0131r ve birbirlerini tamamlarlar. Yedekleme, verilerin bir kopyas\u0131n\u0131 olu\u015fturma ve saklama s\u00fcrecidir. Felaket Kurtarma ise, bir felaket durumunda i\u015f operasyonlar\u0131n\u0131 ve sistemleri yeniden ba\u015flatmak i\u00e7in kullan\u0131lan kapsaml\u0131 bir plan ve s\u00fcre\u00e7ler b\u00fct\u00fcn\u00fcd\u00fcr.<\/p>\n Yedeklemeler, bir DR plan\u0131n\u0131n temel yap\u0131 ta\u015flar\u0131ndan biridir. DR plan\u0131, yedeklemelerin nerede sakland\u0131\u011f\u0131n\u0131, nas\u0131l geri y\u00fcklenece\u011fini, hangi s\u0131rayla sistemlerin aya\u011fa kald\u0131r\u0131laca\u011f\u0131n\u0131, hangi personelin sorumlu oldu\u011funu ve RTO\/RPO hedeflerine nas\u0131l ula\u015f\u0131laca\u011f\u0131n\u0131 ayr\u0131nt\u0131l\u0131 olarak a\u00e7\u0131klar. \u0130yi bir DR plan\u0131, sadece veri kurtarmay\u0131 de\u011fil, ayn\u0131 zamanda altyap\u0131, a\u011f, uygulama ve di\u011fer t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n yeniden olu\u015fturulmas\u0131n\u0131 da kapsar.<\/p>\n \u00dcretim ortam\u0131 web uygulamalar\u0131 i\u00e7in yedekleme, g\u00f6z ard\u0131 edilemeyecek kadar kritik bir konudur. Veri kayb\u0131n\u0131n potansiyel maliyetleri, yedekleme i\u00e7in yap\u0131lan yat\u0131r\u0131mlar\u0131n \u00e7ok \u00f6tesindedir. Kapsaml\u0131 bir yedekleme stratejisi, uygulaman\u0131n kritik verilerini korumakla kalmaz, ayn\u0131 zamanda i\u015f s\u00fcreklili\u011fini sa\u011flar, m\u00fc\u015fteri g\u00fcvenini art\u0131r\u0131r ve yasal uyumluluk gereksinimlerini kar\u015f\u0131lar.<\/p>\n Ba\u015far\u0131l\u0131 bir yedekleme stratejisi; yedeklenmesi gereken veri t\u00fcrlerini do\u011fru belirlemek, uygun metodolojileri ve ara\u00e7lar\u0131 se\u00e7mek, yedekleme s\u0131kl\u0131\u011f\u0131n\u0131 ve saklama politikalar\u0131n\u0131 RPO\/RTO hedefleri do\u011frultusunda ayarlamak, yedekleri g\u00fcvenli ve co\u011frafi olarak yedekli konumlarda saklamak ve en \u00f6nemlisi, yedeklemeleri d\u00fczenli olarak test etmekten ge\u00e7er. Otomasyon, \u015fifreleme, izleme ve belgeleme gibi en iyi uygulamalar, yedekleme sisteminin g\u00fcvenilirli\u011fini ve etkinli\u011fini art\u0131r\u0131r. Unutulmamal\u0131d\u0131r ki, en iyi yedekleme, felaket an\u0131nda sorunsuz bir \u015fekilde kurtarma sa\u011flayan yedeklemedir. Bu nedenle, yedekleme stratejileri s\u00fcrekli olarak g\u00f6zden ge\u00e7irilmeli, g\u00fcncellenmeli ve geli\u015ftirilmelidir.<\/body><\/p>\n","protected":false},"excerpt":{"rendered":"\u00dcretim Ortam\u0131 Web Uygulamalar\u0131 \u0130\u00e7in Kapsaml\u0131 Yedekleme Stratejileri\nWeb uygulamalar\u0131, g\u00fcn\u00fcm\u00fcz dijital ekosisteminin temel ta\u015flar\u0131ndan bir","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-36785","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\npg_dump<\/code>, mysqldump<\/code> gibi ara\u00e7larla veya veritaban\u0131 y\u00f6netim sistemlerinin kendi yedekleme \u00f6zellikleriyle (\u00f6rne\u011fin SQL Server’\u0131n yerle\u015fik yedekleme mekanizmalar\u0131) yedeklenirler. Bu yedeklemeler, genellikle tam veritaban\u0131 d\u00f6k\u00fcmleri, i\u015flem g\u00fcnl\u00fckleri (transaction logs) veya ikili g\u00fcnl\u00fckler (binary logs) \u015feklinde olabilir. Point-in-Time Recovery (PITR) yetene\u011fi sunan \u00e7\u00f6z\u00fcmler, belirli bir ana kadar veritaban\u0131n\u0131 geri y\u00fcklemeyi m\u00fcmk\u00fcn k\u0131lar.
\n* NoSQL Veritabanlar\u0131 (MongoDB, Redis, Cassandra):<\/strong> Her bir NoSQL veritaban\u0131 t\u00fcr\u00fcn\u00fcn kendine \u00f6zg\u00fc yedekleme mekanizmalar\u0131 vard\u0131r. \u00d6rne\u011fin, MongoDB i\u00e7in mongodump<\/code>, Redis i\u00e7in BGSAVE<\/code> komutu veya persistans se\u00e7enekleri (RDB veya AOF), Cassandra i\u00e7in ise anl\u0131k g\u00f6r\u00fcnt\u00fc (snapshot) mekanizmalar\u0131 kullan\u0131l\u0131r.<\/p>\nKullan\u0131c\u0131 Taraf\u0131ndan Y\u00fcklenen Dosyalar ve Statik Varl\u0131klar<\/h3>\n
Log Dosyalar\u0131<\/h3>\n
Yedekleme Stratejileri ve Metodolojileri<\/h2>\n
Tam Yedekleme (Full Backup)<\/h3>\n
Art\u0131ml\u0131 Yedekleme (Incremental Backup)<\/h3>\n
Diferansiyel Yedekleme (Differential Backup)<\/h3>\n
Anl\u0131k G\u00f6r\u00fcnt\u00fc (Snapshot) Yedeklemeleri<\/h3>\n
Yedekleme S\u0131kl\u0131\u011f\u0131 ve Saklama Politikalar\u0131 (RPO\/RTO)<\/h2>\n
Kurtarma Noktas\u0131 Hedefi (RPO – Recovery Point Objective)<\/h3>\n
Kurtarma S\u00fcresi Hedefi (RTO – Recovery Time Objective)<\/h3>\n
Yedekleme S\u0131kl\u0131\u011f\u0131<\/h3>\n
\n* Saatlik\/Yar\u0131 Saatlik:<\/strong> Y\u00fcksek i\u015flem hacmine sahip, kritik veritabanlar\u0131 i\u00e7in tercih edilir. Art\u0131ml\u0131 yedeklemeler veya veritaban\u0131 replikasyonu ile desteklenir.
\n* S\u00fcrekli (Real-time):<\/strong> Veri kayb\u0131n\u0131n kesinlikle kabul edilemez oldu\u011fu durumlar i\u00e7in kullan\u0131l\u0131r. Veritaban\u0131 replikasyonu (master-replica), i\u015flem g\u00fcnl\u00fcklerinin s\u00fcrekli aktar\u0131m\u0131 veya s\u00fcrekli veri koruma (CDP) \u00e7\u00f6z\u00fcmleri ile sa\u011flan\u0131r.<\/p>\nSaklama Politikalar\u0131 (Retention Policies)<\/h3>\n
\n* G\u00fcnl\u00fck yedekler 7-30 g\u00fcn.
\n* Haftal\u0131k yedekler 4-12 hafta.
\n* Ayl\u0131k yedekler 12 ay.
\n* Y\u0131ll\u0131k yedekler 1-7 y\u0131l veya daha uzun.<\/p>\nYedekleme Depolama Konumlar\u0131 ve 3-2-1 Kural\u0131<\/h2>\n
Yerel Depolama (On-site)<\/h3>\n
Uzak\/Bulut Depolama (Off-site\/Cloud)<\/h3>\n
Co\u011frafi Yedeklilik (Geographic Redundancy)<\/h3>\n
3-2-1 Yedekleme Kural\u0131<\/h3>\n
\n1. 3 kopya veriniz olsun:<\/strong> Orijinal veriler ve iki yedek kopya.
\n2. 2 farkl\u0131 depolama ortam\u0131nda saklay\u0131n:<\/strong> \u00d6rne\u011fin, bir kopyay\u0131 yerel diskte, di\u011ferini bulutta.
\n3. 1 kopyay\u0131 uzak (off-site) bir konumda tutun:<\/strong> Orijinal konumdan fiziksel olarak ayr\u0131 bir yerde.<\/p>\nYedekleme Ara\u00e7lar\u0131 ve Teknolojileri<\/h2>\n
Veritaban\u0131 \u00d6zel Ara\u00e7lar\u0131<\/h3>\n
pg_dump<\/code> (PostgreSQL), mysqldump<\/code> (MySQL), mongodump<\/code> (MongoDB):<\/strong> Veritabanlar\u0131n\u0131n mant\u0131ksal yedeklerini (SQL komutlar\u0131 veya BSON format\u0131nda) olu\u015fturan komut sat\u0131r\u0131 ara\u00e7lar\u0131d\u0131r. Genellikle k\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli veritabanlar\u0131 i\u00e7in uygundur.
\n* Veritaban\u0131 Sunucusu Yedekleme \u00d6zellikleri:<\/strong> SQL Server’\u0131n yerle\u015fik yedekleme sihirbazlar\u0131, Oracle RMAN gibi geli\u015fmi\u015f ara\u00e7lar, veritaban\u0131 yedeklemelerini otomatikle\u015ftirir ve Point-in-Time Recovery (PITR) gibi \u00f6zellikleri destekler.
\n* Replikasyon (Replication):<\/strong> Birincil veritaban\u0131n\u0131n (master) verilerini ikincil veritabanlar\u0131na (replica\/slave) s\u00fcrekli olarak kopyalayarak y\u00fcksek eri\u015filebilirlik ve felaket kurtarma sa\u011flar. Yedekleme olarak kabul edilmese de, veri kayb\u0131n\u0131 en aza indirme ve h\u0131zl\u0131 kurtarma sa\u011flama a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahiptir.<\/p>\nDosya Sistemi Ara\u00e7lar\u0131<\/h3>\n
rsync<\/code>:<\/strong> Dosya ve dizinleri yerel veya uzak sistemler aras\u0131nda verimli bir \u015fekilde senkronize etmek ve yedeklemek i\u00e7in kullan\u0131l\u0131r. Yaln\u0131zca de\u011fi\u015fen dosyalar\u0131 kopyalayarak bant geni\u015fli\u011fini ve s\u00fcreyi optimize eder.
\n* tar<\/code>, zip<\/code>:<\/strong> Dosya ve dizinleri s\u0131k\u0131\u015ft\u0131rarak ar\u015fivlemek i\u00e7in kullan\u0131l\u0131r. Basit yedeklemeler ve ar\u015fivleme i\u00e7in uygundur.
\n* duplicity<\/code>, restic<\/code>, borgbackup<\/code>:<\/strong> \u015eifreli, art\u0131ml\u0131 ve depolama alan\u0131 a\u00e7\u0131s\u0131ndan verimli yedeklemeler yapmak i\u00e7in tasarlanm\u0131\u015f a\u00e7\u0131k kaynakl\u0131 ara\u00e7lard\u0131r. Bulut depolama hizmetleriyle entegrasyon sunarlar.<\/p>\nBulut Sa\u011flay\u0131c\u0131 Hizmetleri<\/h3>\n
\n* AWS Backup:<\/strong> EC2 \u00f6rnekleri, EBS birimleri, RDS veritabanlar\u0131, EFS dosya sistemleri ve di\u011fer AWS hizmetleri i\u00e7in merkezi bir yedekleme hizmeti sunar.
\n* Azure Backup:<\/strong> Azure VM’leri, SQL Server veritabanlar\u0131, Azure Dosya Payla\u015f\u0131mlar\u0131 ve di\u011fer Azure hizmetleri i\u00e7in entegre yedekleme ve kurtarma \u00e7\u00f6z\u00fcmleri sa\u011flar.
\n* Google Cloud Backup and DR:<\/strong> Compute Engine VM’leri, veritabanlar\u0131 ve dosya sistemleri i\u00e7in felaket kurtarma yetenekleri de dahil olmak \u00fczere yedekleme hizmetleri sunar.
\n* S3 S\u00fcr\u00fcmleme (Versioning):<\/strong> Amazon S3 gibi nesne depolama hizmetleri, bir nesnenin birden fazla s\u00fcr\u00fcm\u00fcn\u00fc saklayarak yanl\u0131\u015fl\u0131kla silme veya \u00fczerine yazma durumlar\u0131na kar\u015f\u0131 koruma sa\u011flar.<\/p>\n\u00dc\u00e7\u00fcnc\u00fc Taraf Yedekleme \u00c7\u00f6z\u00fcmleri<\/h3>\n
Otomasyon ve Orkestrasyon<\/h3>\n
\n* Cron Jobs:<\/strong> Linux\/Unix sistemlerde belirli zamanlarda betiklerin \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 i\u00e7in kullan\u0131l\u0131r.
\n* Custom Scripts:<\/strong> Python, Bash gibi dillerde yaz\u0131lm\u0131\u015f \u00f6zel betikler, yedekleme mant\u0131\u011f\u0131n\u0131 ve entegrasyonlar\u0131 y\u00f6netir.
\n* Infrastructure as Code (IaC) Ara\u00e7lar\u0131 (Terraform, Ansible):<\/strong> Yedekleme altyap\u0131s\u0131n\u0131n ve politikalar\u0131n\u0131n kod olarak tan\u0131mlanmas\u0131n\u0131 ve y\u00f6netilmesini sa\u011flar.
\n* Orkestrasyon Ara\u00e7lar\u0131 (Kubernetes CronJobs):<\/strong> Konteynerize uygulamalar i\u00e7in yedekleme g\u00f6revlerini programlamak i\u00e7in kullan\u0131l\u0131r.<\/p>\nYedekleme \u00c7\u00f6z\u00fcmlerinin Uygulanmas\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
Otomasyon \u00d6nceli\u011fi<\/h3>\n
Yedeklemeleri \u015eifreleme<\/h3>\n
Yedeklemeleri \u0130zleme<\/h3>\n
D\u00fczenli Yedekleme Testleri<\/h3>\n
Prosed\u00fcrlerin Belgelenmesi<\/h3>\n
Veri Tutarl\u0131l\u0131\u011f\u0131<\/h3>\n
G\u00fcvenlik ve Eri\u015fim Kontrol\u00fc<\/h3>\n
Maliyet Y\u00f6netimi<\/h3>\n
Yasal Uyumluluk<\/h3>\n
Felaket Kurtarma (Disaster Recovery – DR) ve Yedekleme \u0130li\u015fkisi<\/h2>\n
Sonu\u00e7<\/h2>\n