Tablo hep aynı başlar: siteyi açıyorsunuz, tanıdık sayfa yerine sağlayıcının kapanış ekranı geliyor. Panelinize giriyorsunuz, orada kırmızı bir satır duruyor — "Vadesi geçmiş fatura". Hizmet durumu artık "Aktif" değil, "Askıda" ya da "Süresi Doldu" yazıyor. E-postalar da gelmiyor. İlk sorunuz teknik değil, takvimsel: verilerim ne kadar süre orada duracak?
Cevabı internette bulmak beklediğinizden zordur, çünkü dolaşan "30 gün", "redemption süresi", "60 gün sonra silinir" gibi rakamların neredeyse tamamı alan adına aittir, hostinge değil. Alan adı tarafında gerçekten uluslararası bir takvim vardır. Hosting tarafında ise yoktur; süreyi sağlayıcınızın otomasyon ayarları belirler ve iki firma arasında 15 gün ile 90 gün kadar fark olabilir. Yanlış takvimi kendinize uyarlarsanız, hâlâ vaktiniz olduğunu sanırken hesabınız silinmiş olur.
Aşağıda önce bu iki saatin nasıl ayrıştığını netleştireceğim, sonra ödeme gecikmesinin hostingte hangi aşamalardan geçtiğini ve her aşamada neyin hâlâ mümkün olduğunu tablolayacağım. Ardından en pratik kısma geleceğiz: elinizde birkaç saat kaldıysa hangi sırayla ne indirilir ve hangi üç kalem herkes tarafından unutulur. Son olarak kimsenin yüksek sesle konuşmadığı hesabı yapacağız: gecikmiş yenilemeyi ödemek mi ucuz, yoksa sıfırdan kurmak mı?
Hostingin Silinme Takvimi Diye Bir Standart Var mı?#
Kısa cevap: hayır. Alan adı ile hosting bu noktada tamamen farklı iki dünyadır ve karıştırılmaları en pahalı hatadır.
Alan adı bir tescil kaydıdır. Kaydı tutan registry ile ICANN arasındaki sözleşme, süresi dolan bir alan adının hangi aşamalardan geçeceğini yazılı olarak belirler: ödemesiz dönem, ardından kurtarma (redemption) dönemi, sonra silinme bekleme süresi. Bu aşamaların adları ve süreleri sağlayıcıdan sağlayıcıya değişmez; aynı uzantı için herkeste aynı işler. Ayrıntısı redemption ve grace period yazısındadır.
Hosting ise bir kiralama ilişkisidir. Diskte size ayrılan bir alan vardır ve o alanın ne zaman boşaltılacağına karar veren tek merci sağlayıcınızın politikasıdır. Arka planda çalışan fatura otomasyonu iki ayrı ayar tutar: "vade geçtikten kaç gün sonra askıya al" ve "askıya aldıktan kaç gün sonra sonlandır". Bu iki sayı tek ekrandan değiştirilebilir. Yani verinizin ömrü, uluslararası bir kuralın değil, bir ayar alanındaki sayının fonksiyonudur.
| Konu | Alan adı | Hosting |
|---|---|---|
| Takvimi kim belirler | ICANN / registry sözleşmesi | Sağlayıcının kendi politikası |
| Süreler firmadan firmaya değişir mi | Hayır, standarttır | Evet, çok değişir |
| Süre dolunca ilk etki | DNS yayından kalkar, site ve mail durur | Site kapanır, veri diskte kalır |
| Kurtarma dönemi var mı | Evet (redemption), ücreti yüksektir | Sözleşmeye bağlı, garanti değildir |
| Veri kaybı riski | Yok (alan adı veri tutmaz) | Sonlandırmadan sonra kalıcı |
| Geri alma maliyeti | Sabit kurtarma bedeli | Değişken, bazen imkânsız |
Pratik kural: alan adında birkaç haftanız vardır, hostingte ise belirsiz bir süreniz vardır ve onu tahmin etmek yerine öğrenmeniz gerekir.
Alan Adım mı Bitti, Hostingim mi? Önce Bunu Ayırt Edin#
Site kapandığında iki neden de aynı görüntüyü üretebilir, ama yapılacaklar taban tabana zıttır. Ayrımı bir dakikada yapabilirsiniz.
# 1) Kayit bitis tarihi ve durum
whois sirketiniz.com | grep -iE "Expiry|Expiration|Domain Status"
# Registry Expiry Date: 2026-08-02T09:00:00Z -> gectiyse sorun domainde
# Domain Status: redemptionPeriod -> kurtarma doneminde
# Domain Status: clientHold -> yayindan kaldirilmis
# 2) Alan adi hala bir IP'ye cozuluyor mu
dig +short sirketiniz.com A
# 3) Cozuluyorsa sunucu ne cevap veriyor
curl -sI https://sirketiniz.com | head -3
Okuma kılavuzu üç satırdan ibaret:
digboş dönüyorsa sorun alan adı tarafındadır. Sunucunuzdaki veriye hiçbir şey olmamıştır; sadece adres tabelası inmiştir. Yapılacak iş alan adı yenileme sürecidir.digbir IP dönüyor amacurlsağlayıcının kapanış sayfasını gösteriyorsa sorun hostingtedir. Adres tabelası yerinde, kapı kilitli. Bu yazının asıl konusu budur.- İkisi de bozuksa iki hizmet aynı tarihte alınmış ve aynı gün bitmiştir. Bu durumda önce hostingi kurtarın: alan adında saatiniz haftalarla, hostingte günlerle ölçülür.
Ödeme Gecikmesinden Silinmeye: Dört Aşama#
Ödeme kaynaklı yaşam döngüsü, kural ihlali kaynaklı askıya almadan farklı işler. Kural ihlalinde (spam, zararlı yazılım, kaynak aşımı) hesap açılana kadar bir temizlik beklenir; ödeme kaynaklı süreçte tek değişken zamandır. Diğer askı nedenlerini ve çözümlerini hosting hesabım askıya alındı yazısında ele aldık; burada sadece ödeme kolunu izliyoruz.
Aşama 1 — Vade geçti. Fatura ödenmemiştir ama hizmet çalışmaya devam eder. Çoğu sağlayıcı 1-7 gün arası bir tolerans tanır. Bu aşamada hiçbir şey kaybolmaz, sadece gecikme bildirimleri gelir. Bazı firmalar bu noktada bir gecikme bedeli tahakkuk ettirir; sözleşmede genelde "gecikme faizi" ya da "late fee" başlığı altındadır.
Aşama 2 — Askıya alma. Sitenin dışarıya servisi durur, panel girişi ve FTP çoğunlukla kapanır, gelen e-postalar reddedilmeye ya da kuyrukta beklemeye başlar. Ama disk üzerindeki hiçbir şey silinmez. Dosyalarınız ana dizinde, veritabanlarınız MySQL'de, posta kutularınız maildir dizinlerinde olduğu gibi durur. Bu aşama, ödeme yapıldığı anda dakikalar içinde geri alınabilir.
Aşama 3 — Veri saklama penceresi. Askı devam ederken sağlayıcı hesabı hemen silmez, belirli bir süre bekletir. Bu pencere tamamen politikadır: yaygın aralık 7 ile 45 gün arasındadır, bazı firmalar hiç beklemeden ay sonunda siler. Veri hâlâ diskte durur ama erişiminiz kapalıdır — yani "veri duruyor" bilgisi tek başına işinize yaramaz.
Aşama 4 — Sonlandırma. Hesap sunucudan kaldırılır: ana dizin silinir, veritabanları düşürülür, posta kutuları yok edilir. Bu işlem geri alınabilir değildir. Tek umut, sağlayıcının sonlandırmadan önce alınmış bir sunucu yedeğinin hâlâ elinde olmasıdır — ama sağlayıcı yedekleri de dönerlidir (yeni yedek alındıkça en eskisi silinir), yani o pencere de kendi kendine kapanır.
| Aşama | Site | Panel / FTP | Gelen e-posta | Diskteki veri | Geri dönüş |
|---|---|---|---|---|---|
| Vade geçti | Açık | Açık | Geliyor | Yerinde | Ödeme yeterli |
| Askıya alındı | Kapalı | Genelde kapalı | Reddediliyor | Yerinde | Ödeme yeterli |
| Saklama penceresi | Kapalı | Kapalı | Reddediliyor | Yerinde, erişim yok | Ödeme + talep |
| Sonlandırıldı | Kapalı | Yok | Reddediliyor | Silindi | Yalnızca sağlayıcı yedeğinden, garantisiz |
En kritik satır ikinci sıradır: askıdayken veriniz duruyor. Çoğu kişi askı ekranını gördüğü an "sitem silindi" diye düşünüp haftalarca hiçbir şey yapmıyor; gerçek kayıp ise dördüncü aşamada gerçekleşiyor. Kayıp yaşandıysa hangi ihtimallerin kaldığını silinen web sitesi nasıl kurtarılır yazısında topladık.
Kendi Sağlayıcınızın Gerçek Sürelerini Nasıl Öğrenirsiniz#
Tahmin etmeyin; üç kaynaktan kesin bilgi çıkarabilirsiniz.
- Sözleşme metni. "Askıya alma", "fesih" ve "veri saklama" başlıklarını arayın. Aradığınız cümle şu kalıptadır: "Bedeli ödenmeyen hizmet vade tarihinden itibaren … gün sonra askıya alınır, … gün sonra sonlandırılır ve veriler silinir." Bu sayılar sözleşmede yazıyorsa bağlayıcıdır.
- Panelinizdeki hizmet detayı. Hizmet satırında bir sonraki fatura tarihi ve mevcut durum yazar; bazı paneller askıya alma tarihini de gösterir.
- Destek kaydı. Yazılı olarak sorun ve cevabı saklayın. Şu üç maddeyle sorarsanız muğlak cevap alma ihtimaliniz düşer:
1) Hizmetim hangi tarihte askiya alinacak?
2) Askiya alindiktan sonra veriler kac gun diskte tutulup hangi tarihte
sonlandiriliyor?
3) Sonlandirma sonrasi yedekten geri donus mumkun mu, ucretli mi,
kac gun geriye gidiyor?
Üçüncü soru en önemlisidir ve çoğu kişi hiç sormaz. "Yedeğimiz var" cevabı ile "sonlandırılan hesaplar yedeklerden de düşer" cevabı arasında dağlar kadar fark vardır.
Panik Anında İndirme Sırası: Önce Ne Alınır?#
Erişiminiz hâlâ açıksa ya da ödeme yapıp geçici olarak açtırdıysanız, kalan zamanı doğru sırayla kullanın. Mantık tek cümledir: yeniden üretilemeyeni önce alın. Çekirdek dosyaları beş dakikada yeniden indirirsiniz; 2019'dan beri biriken siparişleri hiçbir yerden bulamazsınız.
| Sıra | Kalem | Tipik boyut | Yeniden üretilebilir mi |
|---|---|---|---|
| 1 | Veritabanı | 5-500 MB | Hayır |
| 2 | E-posta kutuları | 100 MB - 20 GB | Hayır |
| 3 | Yapılandırma dosyaları | Birkaç KB | Hayır (ama yeniden yazılabilir) |
| 4 | Yüklenen medya | 100 MB - 50 GB | Kısmen |
| 5 | Cron listesi | Birkaç satır | Hayır (hafızadan yazılamaz) |
| 6 | DNS kayıtları | Birkaç satır | Hayır |
| 7 | SSL özel anahtarı | Birkaç KB | Yeniden üretilir, kesintiye mal olur |
| 8 | Çekirdek ve hazır eklentiler | 50 MB+ | Evet |
Dosya ve veritabanını indirmenin FTP, phpMyAdmin ve panel yedekleyici yöntemlerini adım adım eski hostingden site yedeği alma yazısında anlattık; burada o yöntemleri tekrarlamak yerine sıraya ve herkesin atladığı kalemlere odaklanıyorum.
1-2. Veritabanı ve posta kutuları#
SSH erişiminiz varsa en hızlı yol tek komuttur. Paylaşımlı hostingte kullanıcı adınız ne ise ana diziniz de odur:
# Veritabanini tek dosyaya al (tetikleyiciler ve sakli yordamlar dahil)
mysqldump -u kullanici_db -p --single-transaction --routines --triggers \
--default-character-set=utf8mb4 kullanici_veritabani > veritabani.sql
# Posta kutulari cPanel'de maildir olarak durur
tar -czf posta-kutulari.tar.gz ~/mail
# Dosyalari arsivle (medya en buyuk kalemdir, ayri alin)
tar -czf public_html.tar.gz --exclude='wp-content/uploads' ~/public_html
tar -czf uploads.tar.gz ~/public_html/wp-content/uploads
SSH yoksa posta kutularını IMAP üzerinden kopyalamak en güvenli yoldur. Masaüstü bir istemciye hesabı IMAP olarak ekleyin — POP3 olarak değil, çünkü POP3 varsayılan ayarlarla sunucudaki iletiyi silebilir. Ekledikten sonra klasörleri çevrimdışı kullanıma alın ve senkronizasyonun bittiğini bekleyin. Bu işlem hesap kapanmadan tamamlanmalıdır; kapandıktan sonra IMAP oturumu da açılmaz.
5-6-7. Cron, DNS ve SSL: Herkesin Unuttuğu Üçlü#
Bu üç kalem yedek arşivlerinin hiçbirinde bulunmaz: panel yedekleyicisinden aldığınız arşivde cron satırlarınız, DNS kayıtlarınız ve çoğu zaman SSL özel anahtarınız yoktur. Eksikliği de hemen fark etmezsiniz — üç gün sonra "yedekleme çalışmamış", "fatura e-postaları gitmemiş", "ödeme sayfası sertifika hatası veriyor" şeklinde tek tek patlar.
# Zamanlanmis gorevleri metin olarak disa aktarin
crontab -l > cron-listesi.txt
# Bos cikarsa gorevler panelde tanimlidir:
# cPanel > Cron Jobs ekranindaki tabloyu ekran goruntusuyle saklayin.
DNS tarafında zone transferi (AXFR) neredeyse her yerde kapalıdır, bu yüzden kayıtları tek tek sorgulayıp dosyaya yazmak gerekir:
# Kritik kayit tiplerini toplu dok
for t in SOA NS A AAAA MX TXT CAA; do
dig +noall +answer sirketiniz.com $t
done | tee dns-kayitlari.txt
# Alt alan adlarini da ayrica sorgulayin
for h in www mail ftp cpanel autodiscover; do
dig +noall +answer $h.sirketiniz.com A
dig +noall +answer $h.sirketiniz.com CNAME
done | tee -a dns-kayitlari.txt
# SPF, DKIM ve dogrulama kayitlari en cok unutulanlardir
dig +short TXT sirketiniz.com
dig +short TXT default._domainkey.sirketiniz.com
DKIM seçici adı (default, mail, s1 gibi) sağlayıcıya göre değişir; gelen bir postanın başlıklarındaki DKIM-Signature satırında s= alanından okuyabilirsiniz. Bu kaydı kaybederseniz yeni sunucuda yeni bir anahtar üretmek zorunda kalırsınız ve geçiş gününde e-posta teslim oranınız düşer.
SSL tarafında ücretsiz sertifikalar yeni sunucuda dakikalar içinde üretilir. Ama ücretli, çok yıllık ya da wildcard bir sertifikanız varsa özel anahtar olmadan onu taşıyamazsınız:
# Panelden indirdiginiz ozel anahtari dogrulayin
openssl rsa -in ozel-anahtar.key -check -noout
# Sertifika hangi alan adlarini, hangi tarihe kadar kapsiyor
openssl x509 -in sertifika.crt -noout -subject -dates -ext subjectAltName
# Sertifika ile anahtar eslesiyor mu (iki cikti ayni olmali)
openssl x509 -noout -modulus -in sertifika.crt | openssl md5
openssl rsa -noout -modulus -in ozel-anahtar.key | openssl md5
Son iki komutun çıktısı farklıysa anahtar o sertifikaya ait değildir ve kurulmaz. Bunu taşımadan önce öğrenmek, geçiş gecesi öğrenmekten ucuzdur.
Gecikmiş Yenileme mi, Sıfırdan Kurulum mu?#
Bazen ödemeyi yapmak istemezsiniz: "zaten firma değiştirecektim", "site eskiydi" gibi. Makul bir karar olabilir, ama önce iki tarafı dürüstçe yan yana koymak gerekir. Yapılan hata, gecikmiş yenileme bedelini görünür bir kalem olarak hesaba katıp sıfırdan kurulumun görünmeyen kalemlerini hiç yazmamaktır.
| Kalem | Gecikmiş yenileme | Sıfırdan kurulum |
|---|---|---|
| Doğrudan ödeme | Dönem bedeli + varsa gecikme bedeli | Yeni hosting bedeli |
| Yeniden aktivasyon ücreti | Bazı firmalarda var | Yok |
| İçerik | Yerinde | Yeniden yazılacak veya kayıp |
| E-posta geçmişi | Yerinde | Telafisi yok |
| Sipariş ve müşteri kaydı | Yerinde | Telafisi yok |
| Arama motoru konumu | Kesinti kadar etkilenir | Sıfırdan birikir |
| Sizin harcayacağınız süre | 10 dakika | 10-40 saat |
| Risk | Düşük | Yüksek (unutulan ayrıntılar) |
Pratik bir eşik kuralı: hesapta yeniden üretilemeyen veri varsa — e-posta geçmişi, sipariş kaydı, üyelik tabanı, yıllarca birikmiş içerik — gecikmiş yenilemeyi ödeyip veriyi kurtarmak neredeyse her zaman ucuzdur. Yenileme bedelini "hizmet için ödenen para" olarak değil, "veriye erişim için ödenen anahtar bedeli" olarak düşünün; bir gün için bile ödense verinin yanınıza gelmesini sağlıyorsa işini görmüştür. Ödeyip veriyi indirdikten sonra sözleşmeyi bitirmek her zaman mümkündür.
Tersi de doğrudur: içeriği zaten elinizde olan, e-postası kullanılmayan, tanıtım amaçlı beş sayfalık bir site için gecikmiş yenileme ile yeniden aktivasyon ücretini birlikte ödemek anlamsız olabilir. O durumda ödeme yapmadan önce listenin ilk üç maddesini indirmeye çalışın.
Sonlandırılmış Hesabı Geri Almak: Ne Mümkün, Ne Değil#
Hesap sonlandırıldıysa ihtimaller hızla daralır ama sıfır değildir. Şu sırayla ilerleyin:
- Aynı gün destek kaydı açın. Hizmet adını, alan adını, sonlandırma tarihini ve "sunucu yedeğinden geri dönüş mümkün mü" sorusunu net yazın. Zaman burada aleyhinize çalışır; sağlayıcı yedekleri dönerlidir.
- Ödemeyi yapmaya hazır olduğunuzu belirtin. Çoğu firmada geri dönüş, geçmiş dönem bedelinin ve varsa bir geri yükleme ücretinin ödenmesine bağlıdır.
- Kısmi kurtarmayı kabul edin. Bazen tam hesap dönmez ama veritabanı dökümü ya da ana dizin arşivi çıkarılabilir. Bu bile sıfırdan başlamaktan iyidir.
- Kendi elinizdekileri tarayın. Yerel makinedeki eski FTP kopyaları, geliştiricinizin bilgisayarı, arama motoru önbelleği ve arşiv siteleri metin içeriğin bir kısmını geri getirebilir. Masaüstü posta istemcisi kullanan bir çalışan varsa iletiler o makinede duruyordur.
Bu adımların hiçbiri garanti değildir. Sonlandırmadan sonraki kurtarma, sağlayıcının yedek takvimine bağlıdır — sözleşmeyle talep edebileceğiniz bir hak değildir.
Bir Daha Yaşamamak İçin Kurulacak Üç Şey#
Ödeme kaynaklı kayıpların tamamı önlenebilir kayıplardır ve önlemenin maliyeti sıfıra yakındır.
1. Fatura bildirimleri barındırdığınız alan adına gitmesin. En yaygın kısır döngü budur: hosting kapanır, bildirimler [email protected] adresine gider, o adres de kapalı olduğu için hiçbir uyarıyı görmezsiniz. Panelinizdeki iletişim adresini başka bir sağlayıcıdaki adrese çevirin.
2. Kart son kullanma tarihini takvime yazın. Otomatik ödeme çoğu zaman "kart iptal edildi" diye değil, "kartın süresi doldu" diye başarısız olur ve bu sessiz bir başarısızlıktır.
3. Bitiş tarihini bağımsız izleyin. Alan adı için basit bir kontrol yeterlidir:
#!/usr/bin/env bash
# Alan adi bitisine 30 gunden az kaldiysa uyari yazdirir
DOMAIN="sirketiniz.com"
BITIS=$(whois "$DOMAIN" | grep -im1 "Registry Expiry Date" | cut -d: -f2- | xargs)
KALAN=$(( ( $(date -d "$BITIS" +%s) - $(date +%s) ) / 86400 ))
if [ "$KALAN" -lt 30 ]; then
echo "UYARI: $DOMAIN icin $KALAN gun kaldi (bitis: $BITIS)"
fi
Bu betiği kendi bilgisayarınızda ya da başka bir sunucuda günlük cron'a bağlayın. Kritik nokta şu: izleme betiği, izlediği hizmetin üzerinde çalışmamalıdır — hosting kapandığında üzerindeki uyarı sistemi de kapanır ve tam ihtiyaç duyduğunuz anda susar.
Hosting bitiş tarihi WHOIS'te görünmediği için takip müşteri panelinden yapılır; hizmet detayındaki "sonraki fatura tarihi" alanını takvime elle işlemek yeterlidir. Ödeme dönemi seçiminin bu takvimi nasıl etkilediğini aylık mı yıllık hosting mi yazısında hesapladık.
Sıkça Sorulan Sorular#
Hosting süresi dolduğunda verilerim hemen silinir mi?#
Hayır. Vade geçtiğinde önce kısa bir tolerans süresi, ardından askıya alma gelir ve askıdayken dosyalarınız, veritabanlarınız ve posta kutularınız diskte olduğu gibi durur. Kalıcı kayıp yalnızca sonlandırma aşamasında gerçekleşir. Bu aşamaya kaç gün sonra gelindiği ise sağlayıcının politikasına bağlıdır; sektörde yaygın aralık yedi ile kırk beş gün arasındadır.
Hosting için de redemption süresi var mı?#
Hayır, redemption alan adına özgü bir kavramdır ve ICANN kuralları çerçevesinde işler. Hostingte bunun karşılığı yoktur; sağlayıcının kendi belirlediği bir saklama penceresi vardır ve bu pencere sözleşmede yazmıyorsa bağlayıcı da değildir. İki takvimi karıştırmak, otuz günü olduğunu sanıp verisini kaybeden kullanıcıların en sık yaptığı hatadır.
Ödemeyi yaptım ama sitem hâlâ açılmadı, neden?#
En sık iki sebep var. Birincisi ödemenin başka bir faturaya yazılmış olması: alan adı yenilemesi ya da gelecek dönem faturası kapanmış, gecikmiş fatura açık kalmıştır. Panelde ödenmemiş fatura satırının gerçekten sıfırlandığını doğrulayın. İkincisi havale ve EFT ödemelerinin manuel eşleştirilmesi gerekmesidir; dekontu ilgili faturaya iliştirmezseniz ödeme sahipsiz bekler.
Askıdaki hesaptan yedek alabilir miyim?#
Doğrudan çoğu zaman alamazsınız, çünkü askı sırasında panel, FTP ve SSH kapatılır. Ancak müşteri paneliniz açık kalır; oradan destek kaydı açıp tek seferlik erişim ya da hazır bir yedek arşivi talep edebilirsiniz. Birçok sağlayıcı, borcun ödenmesi koşuluyla bu talebi karşılar. En temiz yol ise gecikmiş dönemi ödeyip hesabı açtırmak, veriyi indirmek, sonra sözleşmeyi sonlandırmaktır.
Yeni sunucuya taşırken en çok unutulan şey nedir?#
Yedek arşivinde bulunmayan üç kalem: zamanlanmış görevler, DNS kayıtları ve SSL özel anahtarı. Bunlar dosya sisteminde tek bir klasörde durmadıkları için panel yedekleyicisi tarafından toplanmaz. Özellikle SPF, DKIM ve doğrulama TXT kayıtlarının kaybı, taşımadan birkaç gün sonra e-postaların spam klasörüne düşmesiyle fark edilir ve nedenini bulmak zaman alır.
Hosting kapanınca alan adım da gider mi?#
Hayır. İkisi ayrı hizmetlerdir ve genellikle ayrı tarihlerde biter. Hosting kapalıyken alan adınız sizde kalır, DNS kayıtlarını düzenleyip siteyi geçici bir sayfaya yönlendirebilirsiniz. Tersi de geçerlidir: alan adı süresi dolduğunda sunucudaki verilere hiçbir şey olmaz, sadece adres çözümlenmediği için siteye ve postaya ulaşılamaz.