{"id":2752,"date":"2026-10-05T20:00:00","date_gmt":"2026-10-05T17:00:00","guid":{"rendered":"https:\/\/narhost.com\/blog\/?p=2752"},"modified":"2026-09-26T23:17:00","modified_gmt":"2026-09-26T20:17:00","slug":"felaket-kurtarma-plani","status":"publish","type":"post","link":"https:\/\/narhost.com\/blog\/felaket-kurtarma-plani\/","title":{"rendered":"Felaket Kurtarma Plan\u0131 Nedir, K\u00fc\u00e7\u00fck \u0130\u015fletmeye Gerekir mi"},"content":{"rendered":"<div id=\"ai-ozet\" class=\"ai-box\">\n<p class=\"ai-box-title\">K\u0131saca \u00f6zet<\/p>\n<ul>\n<li>Felaket kurtarma plan\u0131, sunucu, veri ya da hizmet kayb\u0131 ya\u015fand\u0131\u011f\u0131nda sistemleri hangi s\u0131rayla, kim taraf\u0131ndan ve ne kadar s\u00fcrede geri getirece\u011finizi \u00f6nceden yazan belgedir.<\/li>\n<li>Plan\u0131n iki temel \u00f6l\u00e7\u00fcs\u00fc vard\u0131r: RPO, kaybetmeye raz\u0131 oldu\u011funuz en fazla veri s\u00fcresi; RTO, hizmetin en ge\u00e7 ne kadar s\u00fcrede yeniden a\u00e7\u0131lmas\u0131 gerekti\u011fidir.<\/li>\n<li>K\u00fc\u00e7\u00fck i\u015fletme i\u00e7in d\u00f6rt senaryo yeterli bir ba\u015flang\u0131\u00e7t\u0131r: donan\u0131m ar\u0131zas\u0131, fidye yaz\u0131l\u0131m\u0131, yanl\u0131\u015f silme ve sa\u011flay\u0131c\u0131 ya da hesap kaynakl\u0131 kesinti.<\/li>\n<li>Sade bir plan tek sayfaya s\u0131\u011far: sistem listesi, her sistem i\u00e7in RPO ve RTO, yedeklerin yeri, eri\u015fim bilgilerinin yeri, sorumlu ki\u015fi ve ad\u0131m s\u0131ras\u0131.<\/li>\n<li>Test edilmemi\u015f plan varsay\u0131md\u0131r; y\u0131lda en az bir kez yedekten ger\u00e7ek bir geri d\u00f6n\u00fc\u015f denemesi yap\u0131lmadan RTO rakam\u0131na g\u00fcvenilmez.<\/li>\n<\/ul>\n<\/div>\n<p>\u00c7o\u011fu k\u00fc\u00e7\u00fck i\u015fletme felaket kurtarmay\u0131 bankalar\u0131n ve b\u00fcy\u00fck \u015firketlerin i\u015fi olarak g\u00f6r\u00fcr. Oysa bir g\u00fcn e-ticaret sitesinin a\u00e7\u0131lmamas\u0131, muhasebe dosyalar\u0131n\u0131n \u015fifrelenmesi ya da tek sunucunun diskinin bozulmas\u0131, k\u00fc\u00e7\u00fck i\u015fletmeyi b\u00fcy\u00fck \u015firketten daha sert vurur; \u00e7\u00fcnk\u00fc yedek ekip, yedek sistem ve ayr\u0131lm\u0131\u015f b\u00fct\u00e7e yoktur. Felaket kurtarma plan\u0131 bu a\u00e7\u0131\u011f\u0131 kapatman\u0131n en ucuz yoludur. Bir \u00f6\u011fleden sonra yaz\u0131l\u0131r, kriz an\u0131nda ise saatler kazand\u0131r\u0131r.<\/p>\n<h2>Felaket Kurtarma Plan\u0131 Nedir<\/h2>\n<p>Felaket kurtarma plan\u0131 (disaster recovery plan), bir kesinti ya da veri kayb\u0131ndan sonra BT sistemlerini yeniden \u00e7al\u0131\u015f\u0131r h\u00e2le getirmek i\u00e7in izlenecek ad\u0131mlar\u0131, sorumlular\u0131 ve hedef s\u00fcreleri tan\u0131mlayan yaz\u0131l\u0131 bir belgedir. \u0130\u015f s\u00fcreklili\u011fi plan\u0131n\u0131n teknik aya\u011f\u0131d\u0131r: i\u015f s\u00fcreklili\u011fi &#8220;i\u015fletme kesinti s\u0131ras\u0131nda nas\u0131l \u00e7al\u0131\u015fmaya devam eder&#8221; sorusuna, felaket kurtarma ise &#8220;sistemler nas\u0131l geri gelir&#8221; sorusuna cevap verir.<\/p>\n<p>Konunun resm\u00ee \u00e7er\u00e7evesi, ABD Ulusal Standartlar ve Teknoloji Enstit\u00fcs\u00fc&#8217;n\u00fcn <a href=\"https:\/\/csrc.nist.gov\/pubs\/sp\/800\/34\/r1\/upd1\/final\" title=\"NIST SP 800-34 Rev. 1 \u2014 BT sistemleri i\u00e7in acil durum planlama rehberi\" target=\"_blank\" rel=\"noopener\">SP 800-34 acil durum planlama rehberinde<\/a> \u00e7izilir. Rehber b\u00fcy\u00fck kurumlar i\u00e7in yaz\u0131lm\u0131\u015ft\u0131r, ama temel kavramlar\u0131 k\u00fc\u00e7\u00fck bir i\u015fletmeye de do\u011frudan uyar.<\/p>\n<h2>RPO ve RTO, Plan\u0131n \u0130ki Temel \u00d6l\u00e7\u00fcs\u00fc<\/h2>\n<p><strong>RPO (Recovery Point Objective, kurtarma noktas\u0131 hedefi)<\/strong>, bir olayda kaybetmeye raz\u0131 oldu\u011funuz en fazla veri s\u00fcresidir. RPO&#8217;nuz 24 saat ise son yede\u011finizin en fazla bir g\u00fcn \u00f6nceye ait olmas\u0131 yeterlidir; RPO&#8217;nuz 1 saat ise saatlik bir koruma gerekir. RPO do\u011frudan yedek s\u0131kl\u0131\u011f\u0131n\u0131 belirler.<\/p>\n<p><strong>RTO (Recovery Time Objective, kurtarma s\u00fcresi hedefi)<\/strong>, hizmetin kesintiden sonra en ge\u00e7 ne kadar s\u00fcrede yeniden a\u00e7\u0131lmas\u0131 gerekti\u011fidir. Web sitesi i\u00e7in RTO 4 saat ise yede\u011fin geri y\u00fcklenmesi, gerekiyorsa yeni sunucunun haz\u0131rlanmas\u0131 ve alan ad\u0131n\u0131n y\u00f6nlendirilmesi bu s\u00fcrenin i\u00e7ine s\u0131\u011fmal\u0131d\u0131r. RTO, yede\u011fin nerede durdu\u011funu ve geri y\u00fcklemenin ne kadar s\u00fcrd\u00fc\u011f\u00fcn\u00fc belirler.<\/p>\n<div class=\"highlight-box\">\n<p class=\"label\">Bilgi<\/p>\n<p>RPO ve RTO&#8217;yu teknik ekip de\u011fil, i\u015fletme sahibi belirler. Soru teknik de\u011fil ticaridir: &#8220;Bir g\u00fcnl\u00fck sipari\u015fi kaybetmek bize neye mal olur&#8221; ve &#8220;sitemiz d\u00f6rt saat kapal\u0131 kal\u0131rsa ne kaybederiz&#8221;. Rakam belli olduktan sonra teknik \u00e7\u00f6z\u00fcm ona g\u00f6re se\u00e7ilir; daha k\u0131sa hedef genelde daha y\u00fcksek maliyet demektir.<\/p>\n<\/div>\n<h2>K\u00fc\u00e7\u00fck \u0130\u015fletme \u0130\u00e7in Olas\u0131 Senaryolar<\/h2>\n<p>Her olas\u0131 felaketi planlamaya gerek yoktur. K\u00fc\u00e7\u00fck bir i\u015fletmenin ya\u015fayaca\u011f\u0131 olaylar\u0131n b\u00fcy\u00fck k\u0131sm\u0131 d\u00f6rt senaryoda toplan\u0131r. A\u015fa\u011f\u0131daki tablo her senaryo i\u00e7in \u00f6rnek bir RPO, RTO ve temel \u00f6nlemi g\u00f6steriyor. Rakamlar k\u00fc\u00e7\u00fck bir e-ticaret sitesi i\u00e7in \u00f6rnektir; kendi i\u015fletmenize g\u00f6re de\u011fi\u015ftirin.<\/p>\n<table>\n<thead>\n<tr>\n<th>Senaryo<\/th>\n<th>\u00d6rnek RPO<\/th>\n<th>\u00d6rnek RTO<\/th>\n<th>Temel \u00f6nlem<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Donan\u0131m ya da disk ar\u0131zas\u0131<\/td>\n<td>24 saat<\/td>\n<td>4 saat<\/td>\n<td>Sunucu d\u0131\u015f\u0131nda tutulan g\u00fcncel yedek, yeni sunucuya h\u0131zl\u0131 kurulum ad\u0131mlar\u0131<\/td>\n<\/tr>\n<tr>\n<td>Fidye yaz\u0131l\u0131m\u0131<\/td>\n<td>24 saat<\/td>\n<td>8 saat<\/td>\n<td>\u00c7evrimd\u0131\u015f\u0131 ya da de\u011fi\u015ftirilemez yedek, temiz sistemden kurulum, parolalar\u0131n yenilenmesi<\/td>\n<\/tr>\n<tr>\n<td>Yanl\u0131\u015f silme veya bozuk g\u00fcncelleme<\/td>\n<td>De\u011fi\u015fiklik \u00f6ncesi an<\/td>\n<td>1 saat<\/td>\n<td>B\u00fcy\u00fck de\u011fi\u015fiklikten \u00f6nce manuel yedek, s\u00fcr\u00fcm ge\u00e7mi\u015fi<\/td>\n<\/tr>\n<tr>\n<td>Sa\u011flay\u0131c\u0131 ya da hesap kaynakl\u0131 kesinti<\/td>\n<td>24 saat<\/td>\n<td>24 saat<\/td>\n<td>Sa\u011flay\u0131c\u0131dan ba\u011f\u0131ms\u0131z yerde yedek, alan ad\u0131 ve DNS y\u00f6netimine eri\u015fim<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<div class=\"warn-box\">\n<p class=\"label\">Dikkat<\/p>\n<p>Fidye yaz\u0131l\u0131m\u0131 senaryosunda en s\u0131k g\u00f6r\u00fclen hata, sunucuya ba\u011fl\u0131 yedek klas\u00f6rlerinin de \u015fifrelenmesidir. Sald\u0131rgan\u0131n eri\u015febildi\u011fi yedek, felaket an\u0131nda yedek de\u011fildir. En az bir kopya ba\u011flant\u0131s\u0131 kesilmi\u015f bir ortamda ya da belirli s\u00fcre silinemeyen bir depolamada durmal\u0131d\u0131r. Sald\u0131r\u0131ya u\u011frayan bir sistemin ilk anlar\u0131nda yap\u0131lacaklar\u0131 <a href=\"https:\/\/narhost.com\/blog\/site-hacklenirse-ne-yapmali\/\" title=\"Site Hacklenirse Ne Yapmal\u0131 \u2014 Narhost Blog\">site hacklenirse ne yapmal\u0131 yaz\u0131s\u0131<\/a> s\u0131ral\u0131yor.<\/p>\n<\/div>\n<figure class=\"nh-sema\"><img loading=\"lazy\" src=\"https:\/\/narhost.com\/blog\/wp-content\/uploads\/2026\/09\/felaket-kurtarma-plani-sema-narhost.webp\" alt=\"felaket kurtarma plan\u0131 i\u00e7in sistem listesi, RPO ve RTO, yedek yeri ve test ad\u0131mlar\u0131n\u0131 g\u00f6steren \u015fema\" width=\"1200\" height=\"500\" loading=\"lazy\" decoding=\"async\"><figcaption>Sistemleri listeleyin, hedefleri belirleyin, yede\u011fi ba\u011f\u0131ms\u0131z tutun ve plan\u0131 ger\u00e7ekten deneyin.<\/figcaption><\/figure>\n<h2>Sade Bir Felaket Kurtarma Plan\u0131 \u015eablonu<\/h2>\n<p>K\u00fc\u00e7\u00fck i\u015fletme i\u00e7in etkili bir felaket kurtarma plan\u0131 tek sayfay\u0131 ge\u00e7mez. \u00d6nemli olan uzunluk de\u011fil, kriz an\u0131nda kimsenin tahmin y\u00fcr\u00fctmek zorunda kalmamas\u0131d\u0131r. \u015eablon \u015fu ba\u015fl\u0131klardan olu\u015fur:<\/p>\n<p><strong>Sistem listesi:<\/strong> web sitesi, e-posta, muhasebe yaz\u0131l\u0131m\u0131, m\u00fc\u015fteri veritaban\u0131 gibi kritik sistemler ve her birinin nerede \u00e7al\u0131\u015ft\u0131\u011f\u0131. <strong>Hedefler:<\/strong> her sistem i\u00e7in RPO ve RTO. <strong>Yedeklerin yeri:<\/strong> hangi yede\u011fin nerede durdu\u011fu, ne s\u0131kl\u0131kla yenilendi\u011fi. <strong>Eri\u015fim bilgileri:<\/strong> hosting paneli, alan ad\u0131 hesab\u0131, DNS, bulut depolama; parolalar\u0131n kendisi de\u011fil, \u015fifre y\u00f6neticisindeki yeri. <strong>Sorumlular:<\/strong> birinci ve yedek sorumlu, sa\u011flay\u0131c\u0131lar\u0131n destek ileti\u015fim bilgileri. <strong>Ad\u0131m s\u0131ras\u0131:<\/strong> her senaryo i\u00e7in ilk bir saatte yap\u0131lacak be\u015f-alt\u0131 ad\u0131m.<\/p>\n<p>Plan\u0131n bas\u0131l\u0131 bir kopyas\u0131n\u0131 da saklay\u0131n. Sunucu ya da e-posta \u00e7\u00f6kt\u00fc\u011f\u00fcnde plan\u0131n yaln\u0131zca o sunucuda veya o e-posta kutusunda durmas\u0131, en s\u0131k g\u00f6r\u00fclen ve en can s\u0131k\u0131c\u0131 hatad\u0131r.<\/p>\n<div class=\"senaryo-block\">\n<p class=\"label\">\u00d6rnek senaryo<\/p>\n<p>Alt\u0131 \u00e7al\u0131\u015fanl\u0131 bir mimarl\u0131k ofisi web sitesini ve proje ar\u015fivini bir bulut sunucuda tutuyor. Bir sabah yanl\u0131\u015f \u00e7al\u0131\u015ft\u0131r\u0131lan bir betik proje klas\u00f6r\u00fcn\u00fcn yar\u0131s\u0131n\u0131 siliyor. Ofisin tek sayfal\u0131k plan\u0131nda bu senaryo yaz\u0131l\u0131: sorumlu ki\u015fi sunucuya eri\u015fimi durduruyor, gece al\u0131nan yede\u011fin uzak depolamadaki kopyas\u0131n\u0131 bularak silinen klas\u00f6r\u00fc ayr\u0131 bir dizine geri y\u00fckl\u00fcyor, do\u011frulad\u0131ktan sonra yerine ta\u015f\u0131yor. \u0130\u015f iki saatte bitiyor ve kay\u0131p, planda kabul edilen bir g\u00fcnl\u00fck RPO&#8217;nun i\u00e7inde kal\u0131yor.<\/p>\n<\/div>\n<h2>Yedek, Snapshot ve Kurtarma Aras\u0131ndaki \u0130li\u015fki<\/h2>\n<p>Felaket kurtarma plan\u0131 yede\u011fin yerine ge\u00e7mez, yede\u011fi kullan\u0131labilir h\u00e2le getirir. Yedek RPO&#8217;yu, plan\u0131n geri kalan\u0131 RTO&#8217;yu kar\u015f\u0131lar. Yedek t\u00fcr\u00fc de \u00f6nemlidir. Sunucu diskinin anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcn\u00fc alan snapshot, bozuk bir g\u00fcncellemeden dakikalar i\u00e7inde d\u00f6nmek i\u00e7in \u00e7ok kullan\u0131\u015fl\u0131d\u0131r; ama \u00e7o\u011funlukla ayn\u0131 altyap\u0131da durdu\u011fu i\u00e7in donan\u0131m ya da sa\u011flay\u0131c\u0131 senaryosunda tek ba\u015f\u0131na yetmez. Fark\u0131 <a href=\"https:\/\/narhost.com\/blog\/snapshot-yedek-yerine-gecer-mi\/\" title=\"Snapshot Yedek Yerine Ge\u00e7er mi, VPS&#039;te \u0130kisinin Fark\u0131 \u2014 Narhost Blog\">snapshot yedek yerine ge\u00e7er mi yaz\u0131s\u0131<\/a> ayr\u0131nt\u0131l\u0131 anlat\u0131yor.<\/p>\n<p>Yedeklerin ka\u00e7 kopya ve nerede tutulaca\u011f\u0131, sa\u011flay\u0131c\u0131 se\u00e7erken hangi sorular\u0131n sorulaca\u011f\u0131 gibi konular <a href=\"https:\/\/narhost.com\/blog\/hosting-yedeklemesi-neden-onemli\/\" title=\"Hosting Yedeklemesi Neden \u00d6nemli \u2014 Narhost Blog\">hosting yedeklemesi neden \u00f6nemli yaz\u0131s\u0131nda<\/a> toplan\u0131yor.<\/p>\n<h2>Plan\u0131 Test Etmek Neden \u015eart<\/h2>\n<p>Hi\u00e7 denenmemi\u015f bir planda RTO rakam\u0131 bir tahminden ibarettir. Test s\u0131ras\u0131nda ortaya \u00e7\u0131kan sorunlar hemen her zaman ayn\u0131d\u0131r: yedek ar\u015fivinin parolas\u0131 bilinmiyor, veritaban\u0131 d\u00f6k\u00fcm\u00fc eksik, geri y\u00fckleme beklenenden \u00fc\u00e7 kat uzun s\u00fcr\u00fcyor ya da alan ad\u0131 hesab\u0131na giri\u015f yapacak ki\u015fi izinde. Bunlar\u0131n hepsini kriz an\u0131nda de\u011fil, sakin bir g\u00fcnde \u00f6\u011frenmek istersiniz.<\/p>\n<p>K\u00fc\u00e7\u00fck i\u015fletme i\u00e7in y\u0131lda bir tam deneme yeterli bir ba\u015flang\u0131\u00e7t\u0131r. Yede\u011fi ayr\u0131 bir test ortam\u0131na geri y\u00fckleyin, sitenin a\u00e7\u0131ld\u0131\u011f\u0131n\u0131 ve verilerin g\u00fcncel oldu\u011funu kontrol edin, ge\u00e7en s\u00fcreyi not edin. Dosya, veritaban\u0131 ve e-posta geri y\u00fckleme ad\u0131mlar\u0131 <a href=\"https:\/\/narhost.com\/destek\/yedekten-nasil-geri-yukleme-yapilir\/\" title=\"Yedekten Nas\u0131l Geri Y\u00fckleme Yap\u0131l\u0131r (Dosya\/Veritaban\u0131\/E-posta) \u2014 Narhost Destek Merkezi\">yedekten geri y\u00fckleme kart\u0131nda<\/a> tek tek anlat\u0131l\u0131yor. \u00d6l\u00e7\u00fclen s\u00fcre RTO&#8217;nuzdan uzunsa ya hedefi ya da y\u00f6ntemi de\u011fi\u015ftirin.<\/p>\n<div class=\"success-box\">\n<p class=\"label\">Sonu\u00e7<\/p>\n<p>Felaket kurtarma plan\u0131 k\u00fc\u00e7\u00fck i\u015fletmeye de gerekir, \u00e7\u00fcnk\u00fc kay\u0131p ne kadar k\u00fc\u00e7\u00fck g\u00f6r\u00fcnse de telafisi en zor olan i\u015fletme odur. RPO ve RTO&#8217;yu i\u015fletme olarak belirleyin, d\u00f6rt temel senaryoyu tek sayfal\u0131k bir plana yaz\u0131n, yedeklerden en az birini sa\u011flay\u0131c\u0131dan ba\u011f\u0131ms\u0131z tutun ve plan\u0131 y\u0131lda en az bir kez ger\u00e7ekten deneyin.<\/p>\n<\/div>\n<h2>Bulut Sunucu Kurtarma Plan\u0131nda Nerede Durur<\/h2>\n<p>Donan\u0131m ya da sunucu senaryosunda RTO&#8217;yu en \u00e7ok uzatan ad\u0131m, yede\u011fi geri y\u00fckleyece\u011finiz yeni sunucunun haz\u0131rlanmas\u0131d\u0131r. Narhost bulut sunucular sipari\u015f sonras\u0131 an\u0131nda kurulur, NVMe disk ve 50 Gbps port ile gelir ve Equinix veri merkezinde \u00e7al\u0131\u015f\u0131r; a\u011f katman\u0131nda Layer 3 ve Layer 4 DDoS korumas\u0131 vard\u0131r. Bu, yedekten yeni bir ortam a\u00e7man\u0131z gerekti\u011finde bekleme s\u00fcresini k\u0131salt\u0131r. Sunucunun i\u00e7indeki yedek d\u00fczeni ve geri y\u00fckleme ad\u0131mlar\u0131 ise plan\u0131n\u0131z\u0131n kendisidir. Paketler <a href=\"https:\/\/narhost.com\/bulut-sunucu\" title=\"Narhost Bulut Sunucu paketleri\">bulut sunucu paketleri<\/a> sayfas\u0131nda.<\/p>\n<h2>Kontrol Listesi, Plan\u0131 Yazmadan \u00d6nce<\/h2>\n<ul class=\"kontrol-listesi\">\n<li>\u0130\u015fletmenin \u00e7al\u0131\u015fmas\u0131 i\u00e7in gereken kritik sistemleri tek listede toplay\u0131n.<\/li>\n<li>Her sistem i\u00e7in kabul edilebilir veri kayb\u0131n\u0131 (RPO) ve kesinti s\u00fcresini (RTO) yaz\u0131n.<\/li>\n<li>Yedeklerin nerede durdu\u011funu ve en az birinin sa\u011flay\u0131c\u0131dan ba\u011f\u0131ms\u0131z oldu\u011funu do\u011frulay\u0131n.<\/li>\n<li>Alan ad\u0131, DNS, hosting ve bulut depolama hesaplar\u0131na kimin eri\u015febildi\u011fini belirleyin.<\/li>\n<li>D\u00f6rt temel senaryo i\u00e7in ilk bir saatte yap\u0131lacak ad\u0131mlar\u0131 s\u0131ralay\u0131n.<\/li>\n<li>Plan\u0131n bas\u0131l\u0131 bir kopyas\u0131n\u0131 sunucudan ve e-postadan ba\u011f\u0131ms\u0131z bir yerde saklay\u0131n.<\/li>\n<li>Y\u0131lda en az bir kez yedekten test ortam\u0131na geri y\u00fckleme yap\u0131p s\u00fcreyi \u00f6l\u00e7\u00fcn.<\/li>\n<\/ul>\n<div class=\"kb-faq\">\n<h2>S\u0131k\u00e7a sorulan sorular<\/h2>\n<h3>K\u00fc\u00e7\u00fck bir i\u015fletmenin felaket kurtarma plan\u0131 ne kadar ayr\u0131nt\u0131l\u0131 olmal\u0131?<\/h3>\n<p>Kriz an\u0131nda tek ba\u015f\u0131na okunup uygulanabilecek kadar. \u00c7o\u011fu k\u00fc\u00e7\u00fck i\u015fletme i\u00e7in tek sayfa yeterlidir: kritik sistemler, RPO ve RTO hedefleri, yedeklerin yeri, eri\u015fim bilgilerinin yeri, sorumlular ve her senaryo i\u00e7in ilk ad\u0131mlar. Uzun ve kimsenin okumad\u0131\u011f\u0131 bir belge, k\u0131sa ve g\u00fcncel bir listeden daha az i\u015fe yarar.<\/p>\n<h3>RPO ile RTO aras\u0131ndaki fark nedir, hangisi daha \u00f6nemli?<\/h3>\n<p>RPO ne kadar veri kaybedebilece\u011finizi, RTO ne kadar s\u00fcre kapal\u0131 kalabilece\u011finizi g\u00f6sterir. Hangisinin \u00f6nemli oldu\u011fu i\u015fletmeye ba\u011fl\u0131d\u0131r. Sipari\u015f alan bir ma\u011faza i\u00e7in veri kayb\u0131 daha ac\u0131d\u0131r, RPO k\u0131sal\u0131r; bilgi ama\u00e7l\u0131 bir kurumsal sitede as\u0131l mesele eri\u015filebilirliktir, RTO \u00f6ne \u00e7\u0131kar.<\/p>\n<h3>Hosting firmas\u0131n\u0131n yede\u011fi felaket kurtarma plan\u0131 yerine ge\u00e7er mi?<\/h3>\n<p>Ge\u00e7mez. Sa\u011flay\u0131c\u0131 yede\u011fi plan\u0131n bir par\u00e7as\u0131d\u0131r, plan\u0131n kendisi de\u011fildir. Hesaba eri\u015fimin kesildi\u011fi ya da sorunun yedek aral\u0131\u011f\u0131ndan eski oldu\u011fu durumlarda tek ba\u015f\u0131na yetmez. Sa\u011flay\u0131c\u0131dan ba\u011f\u0131ms\u0131z bir kopya, eri\u015fim bilgileri ve ad\u0131m s\u0131ras\u0131 plan\u0131 tamamlar.<\/p>\n<h3>Felaket kurtarma plan\u0131 ne s\u0131kl\u0131kla g\u00fcncellenmeli?<\/h3>\n<p>En az y\u0131lda bir kez ve her b\u00fcy\u00fck de\u011fi\u015fiklikten sonra. Yeni bir sistem eklendi\u011finde, sa\u011flay\u0131c\u0131 de\u011fi\u015fti\u011finde, sorumlu ki\u015fi i\u015ften ayr\u0131ld\u0131\u011f\u0131nda ya da yedek y\u00f6ntemi de\u011fi\u015fti\u011finde plan eskir. G\u00fcncelleme ile test ayn\u0131 g\u00fcne konursa ikisi de unutulmaz.<\/p>\n<h3>Plan\u0131 test etmek siteyi kapatmay\u0131 gerektirir mi?<\/h3>\n<p>Gerektirmez. Test, canl\u0131 siteye dokunmadan ayr\u0131 bir ortamda yap\u0131l\u0131r: yedek bir test sunucusuna ya da alt alan ad\u0131na geri y\u00fcklenir, sitenin a\u00e7\u0131ld\u0131\u011f\u0131 ve verilerin do\u011fru oldu\u011fu kontrol edilir. Canl\u0131 siteyi kapatarak test yapmak gereksiz bir risktir.<\/p>\n<\/div>\n<div class=\"cta-box\">\n<p class=\"label\">Narhost&#8217;ta<\/p>\n<p>Bulut sunucular\u0131m\u0131z an\u0131nda kurulur, NVMe disk ve 50 Gbps port ile gelir; yedekten yeni bir ortam a\u00e7man\u0131z gerekti\u011finde beklemezsiniz.<\/p>\n<p><a class=\"cta-btn\" href=\"https:\/\/narhost.com\/bulut-sunucu\" title=\"Narhost Bulut Sunucu paketleri\">Bulut sunucu paketlerini incele<\/a><\/div>\n","protected":false},"excerpt":{"rendered":"<p>Felaket kurtarma plan\u0131, sunucu, veri ya da hizmet kayb\u0131nda sistemleri hangi s\u0131rayla, kim taraf\u0131ndan ve ne kadar s\u00fcrede geri getirece\u011finizi \u00f6nceden yazan belgedir. RPO, RTO, d\u00f6rt temel senaryo ve k\u00fc\u00e7\u00fck i\u015fletme i\u00e7in tek sayfal\u0131k \u015fablon bu yaz\u0131da.<\/p>\n","protected":false},"author":1,"featured_media":2753,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-2752","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sunucu"],"_links":{"self":[{"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/posts\/2752","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/comments?post=2752"}],"version-history":[{"count":1,"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/posts\/2752\/revisions"}],"predecessor-version":[{"id":2754,"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/posts\/2752\/revisions\/2754"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/media\/2753"}],"wp:attachment":[{"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/media?parent=2752"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/categories?post=2752"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/narhost.com\/blog\/wp-json\/wp\/v2\/tags?post=2752"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}