{"id":4932,"date":"2026-02-10T19:24:07","date_gmt":"2026-02-10T16:24:07","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/kobiler-icin-rpo-rto-ve-felaket-kurtarma-plani-hosting-tarafinda-gercekci-hedefler\/"},"modified":"2026-02-10T19:24:07","modified_gmt":"2026-02-10T16:24:07","slug":"kobiler-icin-rpo-rto-ve-felaket-kurtarma-plani-hosting-tarafinda-gercekci-hedefler","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/kobiler-icin-rpo-rto-ve-felaket-kurtarma-plani-hosting-tarafinda-gercekci-hedefler\/","title":{"rendered":"KOB\u0130\u2019ler \u0130\u00e7in RPO\/RTO ve Felaket Kurtarma Plan\u0131: Hosting Taraf\u0131nda Ger\u00e7ek\u00e7i Hedefler"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#KOBIler_Icin_RPORTO_Neden_Bu_Kadar_Kritik\"><span class=\"toc_number toc_depth_1\">1<\/span> KOB\u0130\u2019ler \u0130\u00e7in RPO\/RTO Neden Bu Kadar Kritik?<\/a><\/li><li><a href=\"#RPO_ve_RTO_Nedir_KOBI_Duzeyinde_Basit_Tanimlar\"><span class=\"toc_number toc_depth_1\">2<\/span> RPO ve RTO Nedir? KOB\u0130 D\u00fczeyinde Basit Tan\u0131mlar<\/a><ul><li><a href=\"#RPO_Recovery_Point_Objective_nedir\"><span class=\"toc_number toc_depth_2\">2.1<\/span> RPO (Recovery Point Objective) nedir?<\/a><\/li><li><a href=\"#RTO_Recovery_Time_Objective_nedir\"><span class=\"toc_number toc_depth_2\">2.2<\/span> RTO (Recovery Time Objective) nedir?<\/a><\/li><li><a href=\"#Neden_sadece_teknik_ekip_degil_is_birimleri_de_RPORTOya_dahil_olmali\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Neden sadece teknik ekip de\u011fil, i\u015f birimleri de RPO\/RTO\u2019ya dahil olmal\u0131?<\/a><\/li><\/ul><\/li><li><a href=\"#KOBIlerde_En_Sik_Gorulen_RPORTO_Yanilgilari\"><span class=\"toc_number toc_depth_1\">3<\/span> KOB\u0130\u2019lerde En S\u0131k G\u00f6r\u00fclen RPO\/RTO Yan\u0131lg\u0131lar\u0131<\/a><ul><li><a href=\"#8216Yedek_var_o_zaman_guvendeyiz8217_yanilgisi\"><span class=\"toc_number toc_depth_2\">3.1<\/span> &#8216;Yedek var, o zaman g\u00fcvendeyiz&#8217; yan\u0131lg\u0131s\u0131<\/a><\/li><li><a href=\"#8216999_uptime_varsa_her_sey_cozulmustur8217_algisi\"><span class=\"toc_number toc_depth_2\">3.2<\/span> &#8216;%99.9 uptime varsa her \u015fey \u00e7\u00f6z\u00fclm\u00fc\u015ft\u00fcr&#8217; alg\u0131s\u0131<\/a><\/li><li><a href=\"#8216Paylasimli_hosting_kullaniyoruz_RTOmuz_10_dakika_olsun8217_beklentisi\"><span class=\"toc_number toc_depth_2\">3.3<\/span> &#8216;Payla\u015f\u0131ml\u0131 hosting kullan\u0131yoruz, RTO\u2019muz 10 dakika olsun&#8217; beklentisi<\/a><\/li><\/ul><\/li><li><a href=\"#Hosting_Tarafinda_RPORTOyu_Belirleyen_Temel_Bilesenler\"><span class=\"toc_number toc_depth_1\">4<\/span> Hosting Taraf\u0131nda RPO\/RTO\u2019yu Belirleyen Temel Bile\u015fenler<\/a><ul><li><a href=\"#1_Yedekleme_sikligi_ve_turu\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Yedekleme s\u0131kl\u0131\u011f\u0131 ve t\u00fcr\u00fc<\/a><\/li><li><a href=\"#2_Yedeklerin_konumu_ve_dayanikliligi\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Yedeklerin konumu ve dayan\u0131kl\u0131l\u0131\u011f\u0131<\/a><\/li><li><a href=\"#3_Kurtarma_surecinin_otomasyon_seviyesi\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Kurtarma s\u00fcrecinin otomasyon seviyesi<\/a><\/li><li><a href=\"#4_DNS_ve_TTL_stratejisi\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4. DNS ve TTL stratejisi<\/a><\/li><li><a href=\"#5_Izleme_alarm_ve_olay_yonetimi\"><span class=\"toc_number toc_depth_2\">4.5<\/span> 5. \u0130zleme, alarm ve olay y\u00f6netimi<\/a><\/li><\/ul><\/li><li><a href=\"#Farkli_KOBI_Senaryolari_Icin_Gercekci_RPORTO_Hedefleri\"><span class=\"toc_number toc_depth_1\">5<\/span> Farkl\u0131 KOB\u0130 Senaryolar\u0131 \u0130\u00e7in Ger\u00e7ek\u00e7i RPO\/RTO Hedefleri<\/a><ul><li><a href=\"#1_Kurumsal_web_sitesi_ve_blog\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Kurumsal web sitesi ve blog<\/a><\/li><li><a href=\"#2_Eticaret_siteleri\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. E\u2011ticaret siteleri<\/a><\/li><li><a href=\"#3_SaaS_ve_kritik_is_uygulamalari\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. SaaS ve kritik i\u015f uygulamalar\u0131<\/a><\/li><\/ul><\/li><li><a href=\"#Felaket_Kurtarma_Plani_KOBIler_Icin_Adim_Adim_Yaklasim\"><span class=\"toc_number toc_depth_1\">6<\/span> Felaket Kurtarma Plan\u0131: KOB\u0130\u2019ler \u0130\u00e7in Ad\u0131m Ad\u0131m Yakla\u015f\u0131m<\/a><ul><li><a href=\"#1_Varlik_envanteri_ve_bagimliliklar\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. Varl\u0131k envanteri ve ba\u011f\u0131ml\u0131l\u0131klar<\/a><\/li><li><a href=\"#2_Risk_analizi_ve_senaryo_seti\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Risk analizi ve senaryo seti<\/a><\/li><li><a href=\"#3_Sistem_bazinda_RPORTO_hedeflerini_yazili_hale_getirme\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Sistem baz\u0131nda RPO\/RTO hedeflerini yaz\u0131l\u0131 hale getirme<\/a><\/li><li><a href=\"#4_Runbook_ve_sorumluluk_matrisi\"><span class=\"toc_number toc_depth_2\">6.4<\/span> 4. Runbook ve sorumluluk matrisi<\/a><\/li><\/ul><\/li><li><a href=\"#Hosting_Tarafinda_Uygulanabilir_Teknik_Stratejiler\"><span class=\"toc_number toc_depth_1\">7<\/span> Hosting Taraf\u0131nda Uygulanabilir Teknik Stratejiler<\/a><ul><li><a href=\"#1_321_yedekleme_kuralini_KOBI_seviyesine_uyarlamak\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. 3\u20112\u20111 yedekleme kural\u0131n\u0131 KOB\u0130 seviyesine uyarlamak<\/a><\/li><li><a href=\"#2_Immutable_ve_ransomwarea_dayanikli_yedekler\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Immutable ve ransomware\u2019a dayan\u0131kl\u0131 yedekler<\/a><\/li><li><a href=\"#3_Felaket_kurtarma_provasini_gercekten_yapmak\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Felaket kurtarma provas\u0131n\u0131 ger\u00e7ekten yapmak<\/a><\/li><li><a href=\"#4_DNS_ve_cok_bolgeli_mimari_ile_RTOyu_kisaltmak\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. DNS ve \u00e7ok b\u00f6lgeli mimari ile RTO\u2019yu k\u0131saltmak<\/a><\/li><li><a href=\"#5_Izleme_loglama_ve_alarm_kulturunu_yerlestirmek\"><span class=\"toc_number toc_depth_2\">7.5<\/span> 5. \u0130zleme, loglama ve alarm k\u00fclt\u00fcr\u00fcn\u00fc yerle\u015ftirmek<\/a><\/li><\/ul><\/li><li><a href=\"#RPORTO_Hedeflerini_Maliyetle_Dengelemek\"><span class=\"toc_number toc_depth_1\">8<\/span> RPO\/RTO Hedeflerini Maliyetle Dengelemek<\/a><ul><li><a href=\"#Hedefler_sikilastikca_maliyetin_nasil_yukseldigini_gormek\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Hedefler s\u0131k\u0131la\u015ft\u0131k\u00e7a maliyetin nas\u0131l y\u00fckseldi\u011fini g\u00f6rmek<\/a><\/li><li><a href=\"#Is_etkisini_parasal_olarak_kabaca_hesaplamak\"><span class=\"toc_number toc_depth_2\">8.2<\/span> \u0130\u015f etkisini parasal olarak kabaca hesaplamak<\/a><\/li><\/ul><\/li><li><a href=\"#Plani_Test_Etmek_ve_Surekli_Guncel_Tutmak\"><span class=\"toc_number toc_depth_1\">9<\/span> Plan\u0131 Test Etmek ve S\u00fcrekli G\u00fcncel Tutmak<\/a><ul><li><a href=\"#Yillik_minimum_bakim_takvimi\"><span class=\"toc_number toc_depth_2\">9.1<\/span> Y\u0131ll\u0131k minimum bak\u0131m takvimi<\/a><\/li><li><a href=\"#Gercek_olaylardan_ogrenmek\"><span class=\"toc_number toc_depth_2\">9.2<\/span> Ger\u00e7ek olaylardan \u00f6\u011frenmek<\/a><\/li><\/ul><\/li><li><a href=\"#Sonuc_KOBIler_Icin_Uygulanabilir_Bir_Yol_Haritasi\"><span class=\"toc_number toc_depth_1\">10<\/span> Sonu\u00e7: KOB\u0130\u2019ler \u0130\u00e7in Uygulanabilir Bir Yol Haritas\u0131<\/a><\/li><\/ul><\/div>\n<h2><span id=\"KOBIler_Icin_RPORTO_Neden_Bu_Kadar_Kritik\">KOB\u0130\u2019ler \u0130\u00e7in RPO\/RTO Neden Bu Kadar Kritik?<\/span><\/h2>\n<p>KOB\u0130 taraf\u0131nda yapt\u0131\u011f\u0131m\u0131z her toplant\u0131da ayn\u0131 tabloyu g\u00f6r\u00fcyoruz: Web sitesi, e\u2011ticaret altyap\u0131s\u0131 veya SaaS \u00fcr\u00fcn\u00fc i\u015fin merkezinde ama RPO\/RTO sorusunu sordu\u011fumuzda odada sessizlik oluyor. \u00c7o\u011fu zaman yedek al\u0131n\u0131yor mu sorusuna verilen yan\u0131t net bile de\u011fil. Oysa birka\u00e7 saatlik kesinti; sipari\u015f kayb\u0131, CRM verisinin bozulmas\u0131, \u015fube ya da bayilerin sistemlere ula\u015famamas\u0131 gibi \u00e7ok somut kay\u0131plara d\u00f6n\u00fc\u015f\u00fcyor.<\/p>\n<p>Bu yaz\u0131da KOB\u0130\u2019ler i\u00e7in RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) kavramlar\u0131n\u0131 i\u015f taraf\u0131ndan bakarak netle\u015ftirece\u011fiz. Ard\u0131ndan bu hedefleri hosting taraf\u0131nda ger\u00e7ekten hangi mimari ve yedekleme stratejileriyle tutturabilece\u011finizi konu\u015faca\u011f\u0131z. Yani; <a href=\"https:\/\/www.dchost.com\/tr\/web-hosting\">payla\u015f\u0131ml\u0131 hosting<\/a>, <a href=\"https:\/\/www.dchost.com\/tr\/vps\">VPS<\/a>, dedicated veya colocation kullan\u0131yor olun, hangi senaryoda hangi RPO\/RTO aral\u0131klar\u0131 mant\u0131kl\u0131, hangisi b\u00fct\u00e7eyi gereksiz \u015fi\u015firiyor, bunlar\u0131 somut \u00f6rneklerle ele alaca\u011f\u0131z.<\/p>\n<p>DCHost ekibi olarak; e\u2011ticaret, kurumsal web siteleri ve SaaS projeleri i\u00e7in y\u00fczlerce kez kesinti analizi, yedekleme mimarisi ve felaket kurtarma provas\u0131 yapt\u0131k. Burada payla\u015faca\u011f\u0131m\u0131z \u00f6rnekler ve tavsiyeler, do\u011frudan bu ger\u00e7ek deneyimlerin s\u00fczgecinden ge\u00e7mi\u015f durumda. Ayr\u0131ca daha \u00f6nce detayl\u0131 anlatt\u0131\u011f\u0131m\u0131z <a href='https:\/\/www.dchost.com\/blog\/yedekleme-stratejisi-nasil-planlanir-blog-e-ticaret-ve-saas-siteleri-icin-rpo-rto-rehberi\/'>RPO\/RTO odakl\u0131 yedekleme stratejisi rehberi<\/a> ve <a href='https:\/\/www.dchost.com\/blog\/felaket-kurtarma-plani-nasil-yazilir-rto-rpoyu-kafada-netlestirip-yedek-testleri-ve-runbooklari-gercekten-calisir-hale-getirmek\/'>felaket kurtarma plan\u0131 nas\u0131l yaz\u0131l\u0131r<\/a> yaz\u0131lar\u0131ndaki prensipleri, bu kez do\u011frudan KOB\u0130 perspektifinden, daha pratik bir dille \u00f6zetleyece\u011fiz.<\/p>\n<h2><span id=\"RPO_ve_RTO_Nedir_KOBI_Duzeyinde_Basit_Tanimlar\">RPO ve RTO Nedir? KOB\u0130 D\u00fczeyinde Basit Tan\u0131mlar<\/span><\/h2>\n<p>\u00d6nce kavramlar\u0131 sadele\u015ftirelim. Teknik terminolojiyle u\u011fra\u015fmadan, bir i\u015fletme y\u00f6neticisinin anlayaca\u011f\u0131 dille d\u00fc\u015f\u00fcnelim.<\/p>\n<h3><span id=\"RPO_Recovery_Point_Objective_nedir\">RPO (Recovery Point Objective) nedir?<\/span><\/h3>\n<p>RPO; felaket ya\u015fand\u0131\u011f\u0131nda en fazla ne kadarl\u0131k veri kayb\u0131na raz\u0131 oldu\u011funuzu anlat\u0131r. Bunu \u015fu soruyla d\u00fc\u015f\u00fcnebilirsiniz:<\/p>\n<ul>\n<li>&#8216;Sunucu tamamen \u00e7\u00f6kerse, en fazla ka\u00e7 dakika\/saat \u00f6nceki yede\u011fe d\u00f6nmeyi kabul ediyorum?&#8217;<\/li>\n<\/ul>\n<p>\u00d6rnekler:<\/p>\n<ul>\n<li>G\u00fcnde bir yedek alan bir sistemde, teorik RPO yakla\u015f\u0131k 24 saattir.<\/li>\n<li>Her 15 dakikada bir veritaban\u0131 replikasyonu ya da log bazl\u0131 yedek varsa, RPO 15 dakika civar\u0131na iner.<\/li>\n<\/ul>\n<p>Yani RPO; yedeklerin ne s\u0131kl\u0131kla al\u0131nd\u0131\u011f\u0131 ve ne kadar g\u00fcncel oldu\u011fu ile ilgilidir.<\/p>\n<h3><span id=\"RTO_Recovery_Time_Objective_nedir\">RTO (Recovery Time Objective) nedir?<\/span><\/h3>\n<p>RTO ise; felaket an\u0131ndan sistemin tekrar aya\u011fa kalkt\u0131\u011f\u0131 ana kadar ge\u00e7en kabul edilebilir maksimum s\u00fcreyi ifade eder. Di\u011fer bir deyi\u015fle:<\/p>\n<ul>\n<li>&#8216;Sistemim bozulduktan sonra, en ge\u00e7 ne kadar s\u00fcrede tekrar \u00e7al\u0131\u015f\u0131r hale gelmeli?&#8217;<\/li>\n<\/ul>\n<p>\u00d6rnekler:<\/p>\n<ul>\n<li>K\u00fc\u00e7\u00fck bir blog i\u00e7in 4\u20138 saatlik RTO hala kabul edilebilir olabilir.<\/li>\n<li>Yo\u011fun sipari\u015f alan bir e\u2011ticaret sitesi i\u00e7in RTO \u00e7o\u011fu zaman 15\u201360 dakika aras\u0131nda olmal\u0131d\u0131r.<\/li>\n<\/ul>\n<p>RTO; sadece yedekle de\u011fil, kurtarma senaryosunun ne kadar otomatikle\u015fmi\u015f oldu\u011fu, altyap\u0131da haz\u0131r bekleyen yedek sistemler bulunup bulunmad\u0131\u011f\u0131 ve ekibin bu senaryolar\u0131 ne kadar pratikle\u015ftirdi\u011fi ile do\u011frudan ili\u015fkilidir.<\/p>\n<h3><span id=\"Neden_sadece_teknik_ekip_degil_is_birimleri_de_RPORTOya_dahil_olmali\">Neden sadece teknik ekip de\u011fil, i\u015f birimleri de RPO\/RTO\u2019ya dahil olmal\u0131?<\/span><\/h3>\n<p>RPO\/RTO teknik metrik gibi g\u00f6r\u00fcnse de asl\u0131nda tamamen i\u015f karar\u0131d\u0131r. \u00c7\u00fcnk\u00fc:<\/p>\n<ul>\n<li>0 dakikal\u0131k veri kayb\u0131 (RPO=0) ve s\u0131f\u0131ra yak\u0131n RTO, ciddi altyap\u0131 ve operasyon maliyeti gerektirir.<\/li>\n<li>\u0130\u015f birimleri bu maliyetleri, olas\u0131 kay\u0131plarla kar\u015f\u0131la\u015ft\u0131rarak onaylamal\u0131d\u0131r.<\/li>\n<\/ul>\n<p>Bu y\u00fczden KOB\u0130\u2019lerde en sa\u011fl\u0131kl\u0131 yakla\u015f\u0131m; teknik ekip, i\u015f birimleri ve y\u00f6netimin birlikte &#8216;bu sistem en fazla ka\u00e7 dakika kapal\u0131 kalabilir, en fazla ne kadarl\u0131k veriyi kaybetmeyi g\u00f6ze alabiliriz&#8217; sorular\u0131n\u0131 netle\u015ftirmesidir.<\/p>\n<h2><span id=\"KOBIlerde_En_Sik_Gorulen_RPORTO_Yanilgilari\">KOB\u0130\u2019lerde En S\u0131k G\u00f6r\u00fclen RPO\/RTO Yan\u0131lg\u0131lar\u0131<\/span><\/h2>\n<p>Sahada en \u00e7ok kar\u015f\u0131la\u015ft\u0131\u011f\u0131m\u0131z problemler, yanl\u0131\u015f varsay\u0131mlardan kaynaklan\u0131yor. Birka\u00e7 tipik senaryoya bakal\u0131m.<\/p>\n<h3><span id=\"8216Yedek_var_o_zaman_guvendeyiz8217_yanilgisi\">&#8216;Yedek var, o zaman g\u00fcvendeyiz&#8217; yan\u0131lg\u0131s\u0131<\/span><\/h3>\n<p>Bir\u00e7ok i\u015fletmede yedeklerin nerede tutuldu\u011fu, ne s\u0131kl\u0131kla al\u0131nd\u0131\u011f\u0131, geri y\u00fcklenip y\u00fcklenemedi\u011fi net de\u011fil. Hatta bazen:<\/p>\n<ul>\n<li>Yedekler ayn\u0131 fiziksel sunucuda tek diske tutuluyor.<\/li>\n<li>FTP ile manuel yedek al\u0131n\u0131yor ama son dosya 3 ay \u00f6ncesine ait.<\/li>\n<li>Veritaban\u0131 yede\u011fi var ancak dosya sistemi (g\u00f6rseller, upload klas\u00f6r\u00fc vb.) yedeklenmemi\u015f.<\/li>\n<\/ul>\n<p>Sonu\u00e7: Felaket an\u0131nda RPO ka\u011f\u0131t \u00fczerinde 24 saat g\u00f6r\u00fcnse de ger\u00e7ekte 1 hafta veya daha fazla veri kayb\u0131 ya\u015fanabiliyor. Bu da RPO\/RTO hedeflerinin ka\u011f\u0131t \u00fczerinde kalmas\u0131na neden oluyor.<\/p>\n<h3><span id=\"8216999_uptime_varsa_her_sey_cozulmustur8217_algisi\">&#8216;%99.9 uptime varsa her \u015fey \u00e7\u00f6z\u00fclm\u00fc\u015ft\u00fcr&#8217; alg\u0131s\u0131<\/span><\/h3>\n<p>Hosting SLA\u2019lar\u0131nda g\u00f6rd\u00fc\u011f\u00fcn\u00fcz uptime de\u011ferleri; altyap\u0131n\u0131n ne kadar s\u0131k eri\u015filebilir oldu\u011funu anlat\u0131r, veri kayb\u0131 ya da felaket kurtarma s\u00fcresini garanti etmez. Operat\u00f6r kaynakl\u0131 k\u0131sa kesintilerle; yanl\u0131\u015f konfig\u00fcrasyon, ransomware, kritik tablo silinmesi gibi senaryolar tamamen farkl\u0131 ba\u015fl\u0131klard\u0131r.<\/p>\n<p>Bu nedenle uptime oran\u0131 y\u00fcksek bir altyap\u0131 kullan\u0131yor olman\u0131z; RPO\/RTO hedeflerinizi otomatik olarak sa\u011flad\u0131\u011f\u0131n\u0131z anlam\u0131na gelmez. Ayr\u0131 bir felaket kurtarma plan\u0131 ve test edilmi\u015f yedekleme stratejisine ihtiya\u00e7 vard\u0131r.<\/p>\n<h3><span id=\"8216Paylasimli_hosting_kullaniyoruz_RTOmuz_10_dakika_olsun8217_beklentisi\">&#8216;Payla\u015f\u0131ml\u0131 hosting kullan\u0131yoruz, RTO\u2019muz 10 dakika olsun&#8217; beklentisi<\/span><\/h3>\n<p>Ger\u00e7ek\u00e7i olal\u0131m: Standart bir payla\u015f\u0131ml\u0131 hosting hesab\u0131nda, manuel m\u00fcdahale gereken bir felaket senaryosunda (\u00f6rne\u011fin sitenin hacklenmesi veya kullan\u0131c\u0131 hatas\u0131yla silinmesi) 10 dakikal\u0131k RTO \u00e7o\u011fu zaman ger\u00e7ek\u00e7i de\u011fildir. \u00c7\u00fcnk\u00fc:<\/p>\n<ul>\n<li>\u00d6nce problemin fark edilmesi gerekir (izleme yoksa bu bile saatler s\u00fcrebilir).<\/li>\n<li>Son yede\u011fin bulunmas\u0131 ve geri y\u00fckleme s\u00fcreci ba\u015flar.<\/li>\n<li>DNS, cache, CDN gibi katmanlar\u0131n etkisi eklenir.<\/li>\n<\/ul>\n<p>Bu y\u00fczden mimari ve hizmet modeline g\u00f6re RPO\/RTO hedeflerini yeniden kalibre etmek \u015fartt\u0131r. DCHost taraf\u0131nda KOB\u0130 m\u00fc\u015fterilerimizle yapt\u0131\u011f\u0131m\u0131z \u00e7al\u0131\u015fmalarda, bu ger\u00e7ek\u00e7ilik seviyesini en ba\u015ftan oturtmaya \u00f6zellikle dikkat ediyoruz.<\/p>\n<h2><span id=\"Hosting_Tarafinda_RPORTOyu_Belirleyen_Temel_Bilesenler\">Hosting Taraf\u0131nda RPO\/RTO\u2019yu Belirleyen Temel Bile\u015fenler<\/span><\/h2>\n<p>RPO ve RTO hedeflerinizin sahada ger\u00e7ekten tutturulup tutturulamayaca\u011f\u0131n\u0131 belirleyen birka\u00e7 temel teknik unsur var.<\/p>\n<h3><span id=\"1_Yedekleme_sikligi_ve_turu\">1. Yedekleme s\u0131kl\u0131\u011f\u0131 ve t\u00fcr\u00fc<\/span><\/h3>\n<p>RPO\u2019yu do\u011frudan etkileyen ba\u015fl\u0131k buras\u0131:<\/p>\n<ul>\n<li><strong>Tam (full) yedek:<\/strong> T\u00fcm sistemin tek seferde yede\u011fi al\u0131n\u0131r. RPO yedek aral\u0131\u011f\u0131 kadard\u0131r; g\u00fcnl\u00fck al\u0131n\u0131yorsa RPO ~24 saattir.<\/li>\n<li><strong>Art\u0131ml\u0131 (incremental) \/ fark (differential) yedek:<\/strong> Sadece de\u011fi\u015fen veriler al\u0131n\u0131r. Daha s\u0131k yedek almaya uygun oldu\u011fu i\u00e7in RPO\u2019yu d\u00fc\u015f\u00fcrmekte kullan\u0131l\u0131r.<\/li>\n<li><strong>Anl\u0131k g\u00f6r\u00fcnt\u00fc (snapshot):<\/strong> \u00d6zellikle VPS\/dedicated ortamlar\u0131nda disk seviyesinde snapshot\u2019lar ile \u00e7ok d\u00fc\u015f\u00fck RPO de\u011ferleri yakalanabilir.<\/li>\n<\/ul>\n<p>Yedekleme stratejilerini, RPO hedeflerinizi g\u00f6zeterek tasarlaman\u0131z gerekir. Bu konuyu detayl\u0131 anlatt\u0131\u011f\u0131m\u0131z <a href='https:\/\/www.dchost.com\/blog\/yedekleme-stratejisi-nasil-planlanir-blog-e-ticaret-ve-saas-siteleri-icin-rpo-rto-rehberi\/'>yedekleme stratejisi planlama rehberine<\/a> mutlaka g\u00f6z atman\u0131z\u0131 \u00f6neririz.<\/p>\n<h3><span id=\"2_Yedeklerin_konumu_ve_dayanikliligi\">2. Yedeklerin konumu ve dayan\u0131kl\u0131l\u0131\u011f\u0131<\/span><\/h3>\n<p>Yedeklerin nerede tutuldu\u011fu, felaket t\u00fcr\u00fcne g\u00f6re RTO ve hatta RPO\u2019yu do\u011frudan etkiler:<\/p>\n<ul>\n<li><strong>Ayn\u0131 sunucuda tek disk:<\/strong> Donan\u0131m ar\u0131zas\u0131 veya ransomware durumunda hem sistem hem yedek kaybolabilir.<\/li>\n<li><strong>Ayn\u0131 veri merkezinde farkl\u0131 disk \/ depolama:<\/strong> Donan\u0131m riskleri azal\u0131r ama veri merkezi bazl\u0131 felaketlere kar\u015f\u0131 hala savunmas\u0131z kal\u0131rs\u0131n\u0131z.<\/li>\n<li><strong>Farkl\u0131 veri merkezinde uzak yedek:<\/strong> Hem donan\u0131m hem lokasyon bazl\u0131 risklere kar\u015f\u0131 koruma sa\u011flar, fakat geri y\u00fckleme s\u00fcresini (RTO\u2019yu) etkileyebilir.<\/li>\n<li><strong>S3 uyumlu object storage + immutable (de\u011fi\u015ftirilemez) yedekler:<\/strong> Fidye yaz\u0131l\u0131mlara kar\u015f\u0131 ekstra koruma sa\u011flar. <a href='https:\/\/www.dchost.com\/blog\/ransomwarea-dayanikli-hosting-yedekleme-stratejisi-3-2-1-kurali-immutable-backup-ve-air-gap\/'>Ransomware\u2019a dayan\u0131kl\u0131 3\u20112\u20111 yedekleme stratejisi<\/a> tam da bu noktada devreye giriyor.<\/li>\n<\/ul>\n<h3><span id=\"3_Kurtarma_surecinin_otomasyon_seviyesi\">3. Kurtarma s\u00fcrecinin otomasyon seviyesi<\/span><\/h3>\n<p>RTO\u2019yu belirleyen kritik fakt\u00f6rlerden biri de geri y\u00fckleme s\u00fcrecinin ne kadar otomatik oldu\u011fudur:<\/p>\n<ul>\n<li>cPanel hesab\u0131n\u0131 tek t\u0131kla tam yedekten geri d\u00f6nmek ile<\/li>\n<li>VPS \u00fczerinde manuel dosya kopyalama, veritaban\u0131 import etme, konfig\u00fcrasyon dosyalar\u0131n\u0131 elle d\u00fczeltme<\/li>\n<\/ul>\n<p>aras\u0131nda ciddi RTO fark\u0131 vard\u0131r. Benzer \u015fekilde, Terraform\/Ansible gibi ara\u00e7larla altyap\u0131n\u0131n kodla tekrar kurulabiliyor olmas\u0131 da RTO\u2019yu \u00e7arpan etkisiyle d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n<h3><span id=\"4_DNS_ve_TTL_stratejisi\">4. DNS ve TTL stratejisi<\/span><\/h3>\n<p>Bir\u00e7ok KOB\u0130, RTO hesab\u0131nda DNS yay\u0131l\u0131m s\u00fcresini tamamen unutuyor. Oysa bir felaket senaryosunda:<\/p>\n<ul>\n<li>Origin sunucu de\u011fi\u015fti\u011finde A veya AAAA kayd\u0131 g\u00fcncellenir.<\/li>\n<li>Eski y\u00fcksek TTL de\u011ferleri y\u00fcz\u00fcnden, kullan\u0131c\u0131lar\u0131n bir k\u0131sm\u0131 eski IP\u2019ye gitmeye devam eder.<\/li>\n<\/ul>\n<p>Bu y\u00fczden felaket senaryosu i\u00e7eren projelerde, <a href='https:\/\/www.dchost.com\/blog\/dns-ttl-degerlerini-dogru-ayarlamak-a-mx-cname-ve-txt-kayitlari-icin-stratejik-rehber\/'>DNS TTL de\u011ferlerini ba\u015ftan stratejik olarak ayarlamak<\/a> gerekir. Failover kurgusu olan kritik sistemlerde; d\u00fc\u015f\u00fck TTL, \u00e7oklu DNS sa\u011flay\u0131c\u0131 ve health check mekanizmalar\u0131 da RTO\u2019yu azaltmakta etkilidir.<\/p>\n<h3><span id=\"5_Izleme_alarm_ve_olay_yonetimi\">5. \u0130zleme, alarm ve olay y\u00f6netimi<\/span><\/h3>\n<p>RTO sadece kurtarma h\u0131z\u0131na de\u011fil, problemi fark etme s\u00fcresine de ba\u011fl\u0131d\u0131r. E\u011fer:<\/p>\n<ul>\n<li>Uptime, hata oran\u0131, disk doluluk, yedek ba\u015far\u0131s\u0131zl\u0131klar\u0131 i\u00e7in alarm yoksa,<\/li>\n<li>Loglar merkezile\u015ftirilmemi\u015fse,<\/li>\n<li>Olay m\u00fcdahale runbook\u2019lar\u0131 tan\u0131mlanmam\u0131\u015fsa,<\/li>\n<\/ul>\n<p>felaket etkisi gere\u011finden fazla b\u00fcy\u00fcr. Bu nedenle; <a href='https:\/\/www.dchost.com\/blog\/merkezi-sunucu-izleme-ve-alarm-mimarisi\/'>merkezi izleme ve alarm mimarisi<\/a> ile <a href='https:\/\/www.dchost.com\/blog\/web-sitesi-uptime-izleme-ve-alarm-kurma-rehberi\/'>uptime izleme<\/a> ara\u00e7lar\u0131n\u0131 RPO\/RTO plan\u0131n\u0131z\u0131n ayr\u0131lmaz par\u00e7as\u0131 olarak d\u00fc\u015f\u00fcnmeniz gerekir.<\/p>\n<h2><span id=\"Farkli_KOBI_Senaryolari_Icin_Gercekci_RPORTO_Hedefleri\">Farkl\u0131 KOB\u0130 Senaryolar\u0131 \u0130\u00e7in Ger\u00e7ek\u00e7i RPO\/RTO Hedefleri<\/span><\/h2>\n<p>\u015eimdi en s\u0131k kar\u015f\u0131la\u015ft\u0131\u011f\u0131m\u0131z \u00fc\u00e7 tip KOB\u0130 senaryosu \u00fczerinden somut hedef aral\u0131klar\u0131 konu\u015fal\u0131m. Buradaki de\u011ferler elbette her i\u015fletmeye g\u00f6re uyarlanmal\u0131; ancak iyi bir ba\u015flang\u0131\u00e7 noktas\u0131 sunar.<\/p>\n<h3><span id=\"1_Kurumsal_web_sitesi_ve_blog\">1. Kurumsal web sitesi ve blog<\/span><\/h3>\n<p>\u00d6rnekler: Kurumsal tan\u0131t\u0131m sitesi, haber\/blog yay\u0131n\u0131 yapan orta \u00f6l\u00e7ekli i\u015fletmeler, lead toplama ama\u00e7l\u0131 siteler.<\/p>\n<ul>\n<li><strong>\u00d6nerilen RPO:<\/strong> 12\u201324 saat<\/li>\n<li><strong>\u00d6nerilen RTO:<\/strong> 2\u20138 saat<\/li>\n<\/ul>\n<p>Bu tip siteler i\u00e7in tipik mimari:<\/p>\n<ul>\n<li>G\u00fc\u00e7l\u00fc bir payla\u015f\u0131ml\u0131 hosting ya da giri\u015f seviye VPS<\/li>\n<li>G\u00fcnl\u00fck tam yedek + kritik g\u00fcnlerde manuel ekstra yedek<\/li>\n<li>WordPress gibi CMS kullan\u0131l\u0131yorsa veritaban\u0131 ve dosya yedeklerinin birlikte al\u0131nmas\u0131<\/li>\n<\/ul>\n<p>\u00d6nemli ayr\u0131nt\u0131: \u0130\u00e7erik \u00fcretimi \u00e7ok s\u0131k ise (g\u00fcnde onlarca yaz\u0131\/sayfa g\u00fcncellemesi), RPO\u2019yu 6 saate \u00e7ekmek i\u00e7in daha s\u0131k veritaban\u0131 yede\u011fi al\u0131nabilir. \u00d6zellikle WordPress siteler i\u00e7in <a href='https:\/\/www.dchost.com\/blog\/wordpress-yedekleme-stratejileri-paylasimli-hosting-ve-vpste-otomatik-yedek-ve-geri-yukleme\/'>WordPress yedekleme stratejileri<\/a> yaz\u0131m\u0131zdaki pratikleri uygulamak b\u00fcy\u00fck fayda sa\u011flar.<\/p>\n<h3><span id=\"2_Eticaret_siteleri\">2. E\u2011ticaret siteleri<\/span><\/h3>\n<p>\u00d6rnekler: WooCommerce, Magento, OpenCart gibi platformlarla sat\u0131\u015f yapan KOB\u0130 e\u2011ticaret siteleri.<\/p>\n<ul>\n<li><strong>\u00d6nerilen RPO:<\/strong> 5\u201330 dakika (en az\u0131ndan sipari\u015f ve \u00f6deme verileri i\u00e7in)<\/li>\n<li><strong>\u00d6nerilen RTO:<\/strong> 15\u201360 dakika (mesai saatleri i\u00e7inde)<\/li>\n<\/ul>\n<p>Neden bu kadar s\u0131k\u0131? \u00c7\u00fcnk\u00fc burada kaybetti\u011finiz \u015feyler:<\/p>\n<ul>\n<li>Tamamlanm\u0131\u015f sipari\u015f kay\u0131tlar\u0131,<\/li>\n<li>Sepetteki \u00fcr\u00fcnler ve m\u00fc\u015fteri davran\u0131\u015f verileri,<\/li>\n<li>Stok seviyeleri ve muhasebe entegrasyonu.<\/li>\n<\/ul>\n<p>Bu senaryoda tipik yakla\u015f\u0131m:<\/p>\n<ul>\n<li>Veritaban\u0131 i\u00e7in daha s\u0131k (\u00f6rne\u011fin 5\u201315 dakikada bir) transaction log ya da replikasyon tabanl\u0131 yedekleme.<\/li>\n<li>\u00dcr\u00fcn g\u00f6rselleri ve medya i\u00e7in daha seyrek ama g\u00fcvenli object storage yede\u011fi.<\/li>\n<li>VPS veya dedicated \u00fczerinde otomatikle\u015ftirilmi\u015f geri y\u00fckleme betikleri.<\/li>\n<\/ul>\n<p>Burada hem veritaban\u0131 tuning\u2019i hem de yedekleme performans\u0131 kritik oldu\u011fu i\u00e7in, e\u2011ticaret m\u00fc\u015fterilerimizle \u00e7al\u0131\u015f\u0131rken <a href='https:\/\/www.dchost.com\/blog\/woocommerce-icin-ayri-veritabani-ve-onbellek-sunucusu-ne-zaman-mantikli\/'>ayr\u0131 veritaban\u0131 sunucusu ve \u00f6nbellek mimarisi<\/a> gibi konular\u0131 da mutlaka g\u00f6zden ge\u00e7iriyoruz.<\/p>\n<h3><span id=\"3_SaaS_ve_kritik_is_uygulamalari\">3. SaaS ve kritik i\u015f uygulamalar\u0131<\/span><\/h3>\n<p>\u00d6rnekler: M\u00fc\u015fterilere servis verilen SaaS paneller, CRM, rezervasyon sistemleri, bayi portallar\u0131, \u00fcretim veya lojistik takip uygulamalar\u0131.<\/p>\n<ul>\n<li><strong>\u00d6nerilen RPO:<\/strong> 0\u201315 dakika aral\u0131\u011f\u0131 (\u00f6zellikle \u00f6deme, i\u015flem ve log kay\u0131tlar\u0131 i\u00e7in)<\/li>\n<li><strong>\u00d6nerilen RTO:<\/strong> 5\u201330 dakika (kritik i\u015f s\u00fcre\u00e7leri i\u00e7in)<\/li>\n<\/ul>\n<p>Bu hedeflere yakla\u015fmak i\u00e7in genellikle \u015fu mimariler kullan\u0131l\u0131r:<\/p>\n<ul>\n<li>VPS k\u00fcmeleri veya dedicated + replikasyonlu veritaban\u0131<\/li>\n<li>Ger\u00e7ek zamanl\u0131 ya da yak\u0131n ger\u00e7ek zamanl\u0131 veritaban\u0131 replikasyonu<\/li>\n<li>\u0130kincil b\u00f6lgede (farkl\u0131 veri merkezi) haz\u0131r bekleyen yedek ortam (warm standby)<\/li>\n<\/ul>\n<p>B\u00f6yle ortamlarda, basit dosya yede\u011finin \u00f6tesine ge\u00e7mek ve <a href='https:\/\/www.dchost.com\/blog\/cok-bolgeli-mimariler-nasil-kurulur-dns-geo%e2%80%91routing-ve-veritabani-replikasyonu-ile-korkusuz-felaket-dayanikliligi\/'>\u00e7ok b\u00f6lgeli mimari ve veritaban\u0131 replikasyonu<\/a> gibi y\u00f6ntemleri d\u00fc\u015f\u00fcnmek gerekiyor. DCHost olarak bu tarz projelerde RPO\/RTO hedeflerini en ba\u015ftan masaya yat\u0131r\u0131p, b\u00fct\u00e7eyle dengelenmi\u015f ger\u00e7ek\u00e7i bir mimari \u00f6neriyoruz.<\/p>\n<h2><span id=\"Felaket_Kurtarma_Plani_KOBIler_Icin_Adim_Adim_Yaklasim\">Felaket Kurtarma Plan\u0131: KOB\u0130\u2019ler \u0130\u00e7in Ad\u0131m Ad\u0131m Yakla\u015f\u0131m<\/span><\/h2>\n<p>Tek ba\u015f\u0131na yedek yeterli de\u011fil; yede\u011fi nas\u0131l, ne zaman, hangi s\u0131rayla devreye alaca\u011f\u0131n\u0131z\u0131 yaz\u0131l\u0131 bir plana d\u00f6kmedi\u011finiz s\u00fcrece, RPO\/RTO hedefleri ka\u011f\u0131t \u00fczerinde kal\u0131r. Peki KOB\u0130 d\u00fczeyinde uygulanabilir bir felaket kurtarma plan\u0131 nas\u0131l haz\u0131rlanmal\u0131?<\/p>\n<h3><span id=\"1_Varlik_envanteri_ve_bagimliliklar\">1. Varl\u0131k envanteri ve ba\u011f\u0131ml\u0131l\u0131klar<\/span><\/h3>\n<p>\u00d6nce hangi sistemlerin var oldu\u011funu ve birbirlerine nas\u0131l ba\u011fl\u0131 olduklar\u0131n\u0131 listeleyin:<\/p>\n<ul>\n<li>Web uygulamalar\u0131 (site, panel, API vb.)<\/li>\n<li>Veritabanlar\u0131<\/li>\n<li>Dosya depolar\u0131 (upload klas\u00f6r\u00fc, media, object storage)<\/li>\n<li>DNS, e\u2011posta, CDN, \u00f6deme altyap\u0131lar\u0131 gibi d\u0131\u015f ba\u011f\u0131ml\u0131l\u0131klar<\/li>\n<\/ul>\n<p>Daha sonra her varl\u0131\u011f\u0131n i\u015f a\u00e7\u0131s\u0131ndan \u00f6nem derecesini i\u015f birimleriyle birlikte belirleyin. B\u00f6ylece felaket an\u0131nda hangi sistemi \u00f6nce aya\u011fa kald\u0131rman\u0131z gerekti\u011fi netle\u015fir.<\/p>\n<h3><span id=\"2_Risk_analizi_ve_senaryo_seti\">2. Risk analizi ve senaryo seti<\/span><\/h3>\n<p>Her i\u015fletmenin risk profili farkl\u0131d\u0131r. Yine de \u00e7o\u011fu KOB\u0130 i\u00e7in tipik riskler \u015funlard\u0131r:<\/p>\n<ul>\n<li>Veritaban\u0131 tablosunun yanl\u0131\u015fl\u0131kla silinmesi<\/li>\n<li>Ransomware veya web shell ile sitenin \u015fifrelenmesi<\/li>\n<li>Disk ar\u0131zas\u0131 veya dosya sistemi bozulmas\u0131<\/li>\n<li>Veri merkezindeki a\u011f\/elektrik kesintileri<\/li>\n<\/ul>\n<p>Bu riskleri yaz\u0131l\u0131 hale getirip, her biri i\u00e7in &#8216;tetikleyici olay&#8217;, &#8216;ilk tepki&#8217;, &#8216;kurtarma ad\u0131mlar\u0131&#8217; ve &#8216;ileti\u015fim plan\u0131&#8217; ba\u015fl\u0131klar\u0131n\u0131 yazd\u0131\u011f\u0131n\u0131zda, RTO hedefini tutturmak \u00e7ok daha kolayla\u015f\u0131r. Bu k\u0131sm\u0131 detayl\u0131 ele ald\u0131\u011f\u0131m\u0131z <a href='https:\/\/www.dchost.com\/blog\/felaket-kurtarma-plani-nasil-yazilir-rto-rpoyu-kafada-netlestirip-yedek-testleri-ve-runbooklari-gercekten-calisir-hale-getirmek\/'>felaket kurtarma plan\u0131 rehberine<\/a> g\u00f6z atabilirsiniz.<\/p>\n<h3><span id=\"3_Sistem_bazinda_RPORTO_hedeflerini_yazili_hale_getirme\">3. Sistem baz\u0131nda RPO\/RTO hedeflerini yaz\u0131l\u0131 hale getirme<\/span><\/h3>\n<p>Her sistem i\u00e7in \u015fu tabloyu doldurman\u0131z\u0131 \u00f6neririz:<\/p>\n<ul>\n<li>Uygulama ad\u0131<\/li>\n<li>\u0130\u015f kritikli\u011fi (y\u00fcksek\/orta\/d\u00fc\u015f\u00fck)<\/li>\n<li>Hedef RPO (dakika\/saat)<\/li>\n<li>Hedef RTO (dakika\/saat)<\/li>\n<li>Yedekleme y\u00f6ntemi (full, incremental, snapshot vb.)<\/li>\n<li>Kurtarma y\u00f6ntemi (otomatik restore, script, manuel vb.)<\/li>\n<\/ul>\n<p>Bu tabloyu teknik ekiple birlikte doldurup g\u00f6zden ge\u00e7irdi\u011finizde, ger\u00e7ek\u00e7i olmayan talepler \u00e7ok h\u0131zl\u0131 ortaya \u00e7\u0131kar. \u00d6rne\u011fin payla\u015f\u0131ml\u0131 hosting \u00fczerinde \u00e7al\u0131\u015fan bir blog i\u00e7in 5 dakikal\u0131k RPO yaz\u0131ld\u0131ysa; bunun i\u00e7in gereken ek maliyetler masaya yat\u0131r\u0131lmal\u0131d\u0131r.<\/p>\n<h3><span id=\"4_Runbook_ve_sorumluluk_matrisi\">4. Runbook ve sorumluluk matrisi<\/span><\/h3>\n<p>Felaket an\u0131nda kim, neyi, ne kadar s\u00fcrede yapacak? Bu soruya net cevap vermeden RTO hedefi koymak anlaml\u0131 de\u011fildir. Bu nedenle:<\/p>\n<ul>\n<li>Her senaryo i\u00e7in ad\u0131m ad\u0131m yap\u0131lacak i\u015fleri anlatan runbook\u2019lar haz\u0131rlay\u0131n.<\/li>\n<li>Ad\u0131mlar\u0131n yan\u0131na sorumlu ki\u015fi\/ekipleri ve tahmini s\u00fcreleri yaz\u0131n.<\/li>\n<li>\u0130leti\u015fim kanallar\u0131n\u0131 (e\u2011posta, telefon zinciri, Slack\/Teams vb.) belirleyin.<\/li>\n<\/ul>\n<p>DCHost m\u00fc\u015fterilerinin \u00f6nemli bir k\u0131sm\u0131yla; \u00f6zellikle e\u2011ticaret ve SaaS taraf\u0131nda, bu runbook\u2019lar\u0131 birlikte yazarak hem teknik ad\u0131mlar\u0131 sadele\u015ftiriyoruz hem de i\u015f ekiplerinin hangi durumda kiminle ileti\u015fime ge\u00e7ece\u011fini netle\u015ftiriyoruz.<\/p>\n<h2><span id=\"Hosting_Tarafinda_Uygulanabilir_Teknik_Stratejiler\">Hosting Taraf\u0131nda Uygulanabilir Teknik Stratejiler<\/span><\/h2>\n<p>Teoriden prati\u011fe ge\u00e7elim. KOB\u0130 \u00f6l\u00e7e\u011finde ger\u00e7ekten uygulanabilir ve b\u00fct\u00e7eyi patlatmayan baz\u0131 stratejileri \u00f6zetleyelim.<\/p>\n<h3><span id=\"1_321_yedekleme_kuralini_KOBI_seviyesine_uyarlamak\">1. 3\u20112\u20111 yedekleme kural\u0131n\u0131 KOB\u0130 seviyesine uyarlamak<\/span><\/h3>\n<p>3\u20112\u20111 kural\u0131n\u0131n \u00f6z\u00fc \u015fudur:<\/p>\n<ul>\n<li>Verinizin 3 kopyas\u0131 olsun (1 \u00fcretim + 2 yedek)<\/li>\n<li>En az 2 farkl\u0131 ortamda tutun (\u00f6rne\u011fin disk + object storage)<\/li>\n<li>En az 1 kopya farkl\u0131 lokasyonda olsun (uzak veri merkezi)<\/li>\n<\/ul>\n<p>Bunu KOB\u0130 i\u00e7in pratik hale getirmenin yolu:<\/p>\n<ul>\n<li>Sunucu \u00fczerinde yerel g\u00fcnl\u00fck yedek (h\u0131zl\u0131 geri d\u00f6n\u00fc\u015f i\u00e7in)<\/li>\n<li>Farkl\u0131 bir veri merkezindeki object storage\u2019ta \u015fifreli haftal\u0131k yedek<\/li>\n<li>Kritik veritabanlar\u0131 i\u00e7in daha s\u0131k incremental veya binlog tabanl\u0131 yedekleme<\/li>\n<\/ul>\n<p>Object storage ve uzak yedekleme taraf\u0131n\u0131 detayl\u0131 anlatt\u0131\u011f\u0131m\u0131z <a href='https:\/\/www.dchost.com\/blog\/object-storagea-otomatik-yedek-alma-rclone-restic-ve-cron-ile-cpanel-vps-yedekleri\/'>otomatik S3 uyumlu yedekleme rehberi<\/a> ve <a href='https:\/\/www.dchost.com\/blog\/restic-ve-borg-ile-s3-uyumlu-uzak-yedekleme-surumleme-sifreleme-ve-saklama-ne-zaman-nasil\/'>restic\/borg ile uzak yedekleme<\/a> yaz\u0131lar\u0131ndan da faydalanabilirsiniz.<\/p>\n<h3><span id=\"2_Immutable_ve_ransomwarea_dayanikli_yedekler\">2. Immutable ve ransomware\u2019a dayan\u0131kl\u0131 yedekler<\/span><\/h3>\n<p>\u00d6zellikle muhasebe, ERP, CRM gibi verilerin tutuldu\u011fu ortamlarda, fidye yaz\u0131l\u0131m riski art\u0131k teorik de\u011fil, g\u00fcnl\u00fck hayat\u0131n par\u00e7as\u0131. Bu nedenle:<\/p>\n<ul>\n<li>Yedeklerin bir k\u0131sm\u0131n\u0131 immutable (de\u011fi\u015ftirilemez) modda tutmak<\/li>\n<li>Yedek depolama alan\u0131n\u0131 \u00fcretim sunucusundan eri\u015filemez hale getirmek (air\u2011gap mant\u0131\u011f\u0131)<\/li>\n<\/ul>\n<p>gibi ad\u0131mlar RPO\/RTO hedeflerinizin &#8216;ransomware senaryolar\u0131nda&#8217; da ge\u00e7erli kalmas\u0131n\u0131 sa\u011flar. Detaylar i\u00e7in <a href='https:\/\/www.dchost.com\/blog\/ransomwarea-dayanikli-hosting-yedekleme-stratejisi-3-2-1-kurali-immutable-backup-ve-air-gap\/'>ransomware\u2019a dayan\u0131kl\u0131 yedekleme stratejisi<\/a> yaz\u0131m\u0131z\u0131 inceleyebilirsiniz.<\/p>\n<h3><span id=\"3_Felaket_kurtarma_provasini_gercekten_yapmak\">3. Felaket kurtarma provas\u0131n\u0131 ger\u00e7ekten yapmak<\/span><\/h3>\n<p>Plan ne kadar g\u00fczel olursa olsun, en az y\u0131lda bir kez test etmiyorsan\u0131z, RTO tahminlerinizin \u00e7o\u011fu ka\u011f\u0131t \u00fczerindedir. KOB\u0130 \u00f6l\u00e7e\u011finde pratik yakla\u015f\u0131m:<\/p>\n<ul>\n<li>Test ortam\u0131nda en az y\u0131lda 1\u20132 kez tam kurtarma provas\u0131 yapmak<\/li>\n<li>cPanel tam yedekten farkl\u0131 bir sunucuya geri d\u00f6n\u00fc\u015f denemek<\/li>\n<li>VPS snapshot\u2019lar\u0131ndan veya veritaban\u0131 yedeklerinden aya\u011fa kalkma s\u00fcrelerini \u00f6l\u00e7mek<\/li>\n<\/ul>\n<p>Bu konuda ad\u0131m ad\u0131m \u00f6rnekleri <a href='https:\/\/www.dchost.com\/blog\/hosting-tarafinda-felaket-kurtarma-provasi-cpanel-ve-vps-yedeklerini-test-etme-rehberi\/'>hosting taraf\u0131nda felaket kurtarma provas\u0131<\/a> rehberimizde detayl\u0131 anlatt\u0131k. Prova sonucunda ger\u00e7ek RTO s\u00fcrelerinizi \u00f6l\u00e7\u00fcp plan\u0131n\u0131z\u0131 revize etmeniz, en kritik ad\u0131md\u0131r.<\/p>\n<h3><span id=\"4_DNS_ve_cok_bolgeli_mimari_ile_RTOyu_kisaltmak\">4. DNS ve \u00e7ok b\u00f6lgeli mimari ile RTO\u2019yu k\u0131saltmak<\/span><\/h3>\n<p>Kritik sistemler i\u00e7in, tek veri merkezine ba\u011f\u0131ml\u0131 kalmamak b\u00fcy\u00fck avantaj sa\u011flar. \u00d6rne\u011fin:<\/p>\n<ul>\n<li>Birincil b\u00f6lgede \u00e7al\u0131\u015fan ana VPS k\u00fcmeleri<\/li>\n<li>\u0130kincil b\u00f6lgede daha k\u00fc\u00e7\u00fck ama senkronize bir warm standby ortam<\/li>\n<li>DNS health check ve otomatik failover kurallar\u0131<\/li>\n<\/ul>\n<p>ile veri merkezi kapsaml\u0131 kesintilerde bile RTO\u2019yu dakikalar seviyesinde tutabilirsiniz. Bu kurgunun prensiplerini <a href='https:\/\/www.dchost.com\/blog\/kucuk-isletme-siteleri-icin-multi-region-dns-ve-cdn-failover-mimarisi\/'>multi\u2011region DNS ve CDN failover mimarisi<\/a> yaz\u0131m\u0131zda pratik \u00f6rneklerle ele ald\u0131k.<\/p>\n<h3><span id=\"5_Izleme_loglama_ve_alarm_kulturunu_yerlestirmek\">5. \u0130zleme, loglama ve alarm k\u00fclt\u00fcr\u00fcn\u00fc yerle\u015ftirmek<\/span><\/h3>\n<p>RPO\/RTO haritas\u0131 tamamlan\u0131rken \u00e7o\u011fu KOB\u0130\u2019nin atlad\u0131\u011f\u0131 nokta; sorunu erken fark etmeyi sa\u011flayacak g\u00f6r\u00fcn\u00fcrl\u00fck katman\u0131. En az\u0131ndan:<\/p>\n<ul>\n<li>HTTP 5xx hatalar\u0131na alarm<\/li>\n<li>Yedek ba\u015far\u0131s\u0131zl\u0131klar\u0131na alarm<\/li>\n<li>Disk doluluk ve y\u00fcksek CPU\/IO kullan\u0131m\u0131na alarm<\/li>\n<\/ul>\n<p>kurulmad\u0131\u011f\u0131 s\u00fcrece, RTO hedefleri ger\u00e7ek\u00e7i olmaz. Bu nedenle; DCHost \u00fczerinde \u00e7al\u0131\u015fan VPS ve dedicated m\u00fc\u015fterilerimize genellikle <a href='https:\/\/www.dchost.com\/blog\/vps-izleme-ve-alarm-kurulumu-prometheus-grafana-ve-uptime-kuma-ile-baslangic\/'>Prometheus\/Grafana + Uptime Kuma<\/a> gibi \u00e7\u00f6z\u00fcmlerle basit ama etkili bir izleme katman\u0131 \u00f6nermekteyiz.<\/p>\n<h2><span id=\"RPORTO_Hedeflerini_Maliyetle_Dengelemek\">RPO\/RTO Hedeflerini Maliyetle Dengelemek<\/span><\/h2>\n<p>Her KOB\u0130\u2019nin b\u00fct\u00e7esi s\u0131n\u0131rl\u0131; bu y\u00fczden &#8216;maksimum g\u00fcvenlik, minimum kesinti&#8217; iste\u011fini daha rasyonel bir \u00e7er\u00e7eveye oturtmak gerekiyor.<\/p>\n<h3><span id=\"Hedefler_sikilastikca_maliyetin_nasil_yukseldigini_gormek\">Hedefler s\u0131k\u0131la\u015ft\u0131k\u00e7a maliyetin nas\u0131l y\u00fckseldi\u011fini g\u00f6rmek<\/span><\/h3>\n<p>Basitle\u015ftirilmi\u015f bir \u00f6rnek d\u00fc\u015f\u00fcnelim:<\/p>\n<ul>\n<li><strong>Senaryo A:<\/strong> RPO 24 saat, RTO 8 saat \u2013 G\u00fcndelik kurumsal site<\/li>\n<li><strong>Senaryo B:<\/strong> RPO 1 saat, RTO 1 saat \u2013 Orta seviye e\u2011ticaret<\/li>\n<li><strong>Senaryo C:<\/strong> RPO 5 dakika, RTO 10 dakika \u2013 Kritik SaaS<\/li>\n<\/ul>\n<p>Senaryo A\u2019dan C\u2019ye ge\u00e7erken:<\/p>\n<ul>\n<li>Daha s\u0131k yedekleme \u2192 daha fazla depolama ve i\u015flem maliyeti<\/li>\n<li>\u0130kincil ortam ve replikasyon \u2192 ek sunucu maliyeti<\/li>\n<li>Otomasyon, izleme, testler \u2192 daha fazla operasyonel zaman<\/li>\n<\/ul>\n<p>Yani her &#8216;dakika s\u0131k\u0131la\u015ft\u0131rmas\u0131&#8217; bir maliyet \u00e7arpan\u0131 getiriyor. Bu y\u00fczden \u00f6nce i\u015f kayb\u0131n\u0131n parasal kar\u015f\u0131l\u0131\u011f\u0131n\u0131 hesaplamadan, RPO\/RTO hedeflerini s\u0131k\u0131la\u015ft\u0131rmak sa\u011fl\u0131kl\u0131 de\u011fil.<\/p>\n<h3><span id=\"Is_etkisini_parasal_olarak_kabaca_hesaplamak\">\u0130\u015f etkisini parasal olarak kabaca hesaplamak<\/span><\/h3>\n<p>KOB\u0130\u2019ler i\u00e7in basit bir \u00e7er\u00e7eve i\u015fe yar\u0131yor:<\/p>\n<ul>\n<li>Saatlik ortalama ciro veya m\u00fc\u015fteri i\u015flemi de\u011ferini \u00e7\u0131kar\u0131n.<\/li>\n<li>\u0130tibar, m\u00fc\u015fteri memnuniyeti, s\u00f6zle\u015fme cezalar\u0131 gibi kalemler i\u00e7in bir katsay\u0131 ekleyin.<\/li>\n<li>Diyelim ki 1 saatlik kesintinin i\u015fletmenize ortalama X TL maliyeti var.<\/li>\n<\/ul>\n<p>Ard\u0131ndan altyap\u0131n\u0131z\u0131 bir \u00fcst seviyeye ta\u015f\u0131mak i\u00e7in gereken ek maliyeti hesaplay\u0131n. E\u011fer fazladan yat\u0131rd\u0131\u011f\u0131n\u0131z her 1 TL, size olas\u0131 zarar taraf\u0131nda 2\u20133 TL tasarruf olarak d\u00f6n\u00fcyorsa, RPO\/RTO\u2019yu s\u0131k\u0131la\u015ft\u0131rmak rasyonel bir karard\u0131r.<\/p>\n<h2><span id=\"Plani_Test_Etmek_ve_Surekli_Guncel_Tutmak\">Plan\u0131 Test Etmek ve S\u00fcrekli G\u00fcncel Tutmak<\/span><\/h2>\n<p>Felaket kurtarma ve RPO\/RTO, &#8216;bir kere yaz\u0131p rafa kald\u0131rd\u0131\u011f\u0131m\u0131z&#8217; dok\u00fcmanlar de\u011fildir. \u00d6zellikle KOB\u0130\u2019lerde;<\/p>\n<ul>\n<li>Yeni mod\u00fcller devreye girer,<\/li>\n<li>Yeni entegrasyonlar eklenir,<\/li>\n<li>Ekibin bile\u015fimi ve yetkinlikleri de\u011fi\u015fir.<\/li>\n<\/ul>\n<p>Bu nedenle y\u0131llar \u00f6nce yaz\u0131lm\u0131\u015f ve hi\u00e7 g\u00fcncellenmemi\u015f bir DR plan\u0131n\u0131n, ger\u00e7ek bir olayda i\u015fe yaramas\u0131n\u0131 beklemek hayalcilik olur.<\/p>\n<h3><span id=\"Yillik_minimum_bakim_takvimi\">Y\u0131ll\u0131k minimum bak\u0131m takvimi<\/span><\/h3>\n<p>KOB\u0130 seviyesinde uygulanabilir, basit bir rutin \u00f6nerebiliriz:<\/p>\n<ul>\n<li>Y\u0131lda en az 1 kez tam DR senaryosu provas\u0131 (test ortam\u0131nda)<\/li>\n<li>Her 6 ayda bir RPO\/RTO tablolar\u0131n\u0131n g\u00f6zden ge\u00e7irilmesi<\/li>\n<li>Yeni uygulamalar devreye girdik\u00e7e, envanter ve runbook\u2019lara eklenmesi<\/li>\n<\/ul>\n<p>Bu s\u00fcreci; <a href='https:\/\/www.dchost.com\/blog\/kucuk-isletmeler-icin-yillik-web-sitesi-bakim-takvimi\/'>k\u00fc\u00e7\u00fck i\u015fletmeler i\u00e7in y\u0131ll\u0131k bak\u0131m takvimi<\/a> ile entegre etmek de pratik bir y\u00f6ntemdir.<\/p>\n<h3><span id=\"Gercek_olaylardan_ogrenmek\">Ger\u00e7ek olaylardan \u00f6\u011frenmek<\/span><\/h3>\n<p>Ne kadar prova yaparsak yapal\u0131m, ger\u00e7ek bir kesinti veya veri kayb\u0131 olay\u0131 ya\u015fand\u0131\u011f\u0131nda mutlaka beklenmedik detaylar ortaya \u00e7\u0131kar. Her b\u00f6yle olay sonras\u0131:<\/p>\n<ul>\n<li>Olay sonras\u0131 inceleme (post\u2011mortem) yap\u0131n.<\/li>\n<li>Hangi ad\u0131mlar i\u015fe yarad\u0131, hangileri t\u0131kand\u0131, bunlar\u0131 not edin.<\/li>\n<li>RPO\/RTO hedeflerini ve runbook\u2019lar\u0131 bu \u00f6\u011frenimlerle g\u00fcncelleyin.<\/li>\n<\/ul>\n<p>DCHost olarak ciddi her vaka sonras\u0131nda m\u00fc\u015fterilerimizle birlikte teknik ve operasyonel dersleri \u00e7\u0131kar\u0131p, ilgili dok\u00fcmanlar\u0131 g\u00fcncellemek i\u00e7in zaman ay\u0131r\u0131yoruz. Uzun vadede en \u00e7ok fayday\u0131 sa\u011flayan ad\u0131m\u0131n bu oldu\u011funu rahatl\u0131kla s\u00f6yleyebiliriz.<\/p>\n<h2><span id=\"Sonuc_KOBIler_Icin_Uygulanabilir_Bir_Yol_Haritasi\">Sonu\u00e7: KOB\u0130\u2019ler \u0130\u00e7in Uygulanabilir Bir Yol Haritas\u0131<\/span><\/h2>\n<p>\u00d6zetleyelim:<\/p>\n<ul>\n<li>RPO ve RTO teknik kavramlar gibi g\u00f6r\u00fcnse de asl\u0131nda i\u015f kararlar\u0131d\u0131r; y\u00f6netim ve i\u015f birimleri mutlaka s\u00fcrece dahil olmal\u0131d\u0131r.<\/li>\n<li>Payla\u015f\u0131ml\u0131 hosting, VPS, dedicated veya colocation hangi modeli kullan\u0131yor olursan\u0131z olun; her biri i\u00e7in ger\u00e7ek\u00e7i RPO\/RTO s\u0131n\u0131rlar\u0131 vard\u0131r.<\/li>\n<li>3\u20112\u20111 kural\u0131, immutable yedekler, uzak veri merkezi, DNS\/TTL stratejisi ve izleme; felaket kurtarma mimarisinin temel ta\u015flar\u0131d\u0131r.<\/li>\n<li>Plan\u0131n ka\u011f\u0131t \u00fczerinde kalmamas\u0131 i\u00e7in y\u0131lda en az bir kez <a href='https:\/\/www.dchost.com\/blog\/hosting-tarafinda-felaket-kurtarma-provasi-cpanel-ve-vps-yedeklerini-test-etme-rehberi\/'>felaket kurtarma provas\u0131<\/a> yap\u0131lmal\u0131 ve sonu\u00e7lara g\u00f6re g\u00fcncellenmelidir.<\/li>\n<\/ul>\n<p>E\u011fer siz de i\u015fletmeniz i\u00e7in &#8216;Bu sistem en fazla ka\u00e7 dakika kapal\u0131 kalabilir, en fazla ne kadar veri kayb\u0131na katlanabiliriz?&#8217; sorular\u0131n\u0131 netle\u015ftirmek istiyorsan\u0131z, DCHost ekibi olarak RPO\/RTO hedeflerinizi birlikte masaya yat\u0131rmaktan memnuniyet duyar\u0131z. Mevcut altyap\u0131n\u0131z\u0131, yedekleme d\u00fczeninizi ve i\u015f \u00f6nceliklerinizi inceleyip; b\u00fct\u00e7enize uygun, ger\u00e7ek\u00e7i ve s\u00fcrd\u00fcr\u00fclebilir bir felaket kurtarma plan\u0131n\u0131 beraber tasarlayabiliriz.<\/p>\n<p>\u0130lk ad\u0131m olarak, dahili ekibinizle k\u0131sa bir oturum yap\u0131p bu yaz\u0131da bahsetti\u011fimiz tabloyu doldurun; ard\u0131ndan bizimle payla\u015ft\u0131\u011f\u0131n\u0131zda, DCHost altyap\u0131s\u0131 \u00fczerinde hangi hosting, yedekleme ve DR mimarisinin sizin i\u00e7in do\u011fru oldu\u011funu somut \u00f6nerilerle konu\u015fabiliriz.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 KOB\u0130\u2019ler \u0130\u00e7in RPO\/RTO Neden Bu Kadar Kritik?2 RPO ve RTO Nedir? KOB\u0130 D\u00fczeyinde Basit Tan\u0131mlar2.1 RPO (Recovery Point Objective) nedir?2.2 RTO (Recovery Time Objective) nedir?2.3 Neden sadece teknik ekip de\u011fil, i\u015f birimleri de RPO\/RTO\u2019ya dahil olmal\u0131?3 KOB\u0130\u2019lerde En S\u0131k G\u00f6r\u00fclen RPO\/RTO Yan\u0131lg\u0131lar\u01313.1 &#8216;Yedek var, o zaman g\u00fcvendeyiz&#8217; yan\u0131lg\u0131s\u01313.2 &#8216;%99.9 uptime varsa her \u015fey \u00e7\u00f6z\u00fclm\u00fc\u015ft\u00fcr&#8217; [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4933,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4932","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/4932","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/comments?post=4932"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/posts\/4932\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media\/4933"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/media?parent=4932"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/categories?post=4932"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/wp-json\/wp\/v2\/tags?post=4932"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}