Buluta Geçiş Rehberi: 10 Adımda Taşıma Planı

Buluta geçiş için güvenli yol, önce mevcut sistemi ölçüp belgelemek, ardından hedef ortamda tam bir prova yapmak ve DNS değişikliğinden sonra uygulama davranışını doğrulamaktır. Dosyaları kopyalamak tek başına yeterli değildir; veritabanı tutarlılığı, gizli bilgiler, yedek geri dönüşü ve başarısızlık hâlinde eski ortama dönüş planı da hazır olmalıdır.

Buluta geçiş nereden başlamalı?

Buluta geçiş, dosyaları bir sunucudan diğerine kopyalamaktan ibaret değildir. Uygulama, veritabanı, DNS, güvenlik, yedekleme, izleme ve geri dönüş planı birlikte taşınmalıdır. Sağlıklı bir plan önce envanterle başlar; ardından test ortamında prova, sonunda ölçülebilir bir kesim ve doğrulama yapılır.

1. Mevcut sistemi envanterleyin

İlk adım, hangi bileşenlerin gerçekten taşınacağını ve hangilerinin emekliye ayrılacağını yazılı hâle getirmektir. Sunucu listesi, işletim sistemi sürümleri, CPU ve RAM kullanımı, disk kapasitesi, açık portlar, çalışan servisler, cron görevleri, DNS kayıtları ve dış servis bağımlılıkları aynı tabloda bulunmalıdır.

Linux sunucuda başlangıç için şu komutlar yeterli bir fotoğraf sunar:

hostnamectl
lsblk
free -h
ss -tulpn
systemctl list-units --type=service --state=running
crontab -l

ss -tulpn çıktısındaki her dinleme portunu bir uygulama veya yönetim ihtiyacıyla eşleştirin. Kullanılmayan bir portu yeni ortama taşımak, eski düzensizliği buluta kopyalamaktır. Nginx kullanan sitelerde Ubuntu’da Nginx Kurulumu ve İlk Yapılandırma başlığındaki temel sanal host ve servis kontrolleri de envantere yardımcı olur.

Veri sınıflandırması da burada yapılmalıdır. Veritabanı, kullanıcı yüklemeleri, oturum dosyaları, gizli anahtarlar ve loglar aynı taşıma yöntemiyle ele alınmaz. Her biri için boyut, değişim sıklığı, erişim yetkisi ve kabul edilebilir veri kaybı süresi yazılmalıdır.

Envanteri tamamlayın – Her servis, port, veri dizini, DNS kaydı ve dış bağımlılık için bir sahip ve doğrulama yöntemi belirleyin.

2. Hedef mimariyi ve sorumlulukları seçin

Bulut sağlayıcısında sanal makine, yönetilen veritabanı, nesne depolama veya konteyner platformu arasında seçim yaparken yalnızca aylık fiyatı karşılaştırmayın. Yönetim yükü, yedekleme modeli, ağ çıkış ücretleri, bölge seçimi, erişim kontrolü ve sağlayıcıya bağımlılık da hesaba katılmalıdır.

Paylaşılan sorumluluk modelinde sağlayıcı fiziksel altyapıyı korur; işletim sistemi, uygulama, kimlik bilgileri ve veri güvenliği seçilen hizmete göre müşteride kalabilir. Yönetilen hizmet kullanılması, yedekleme sorumluluğunu otomatik olarak ortadan kaldırmaz.

3. Kaynak ve maliyet hesabını gerçek kullanımla yapın

Yeni sanal makinenin boyutunu eski sunucunun etiketine bakarak seçmeyin. En az 7 günlük CPU, bellek, disk doluluğu, disk gecikmesi, ağ trafiği ve istek sayısı ölçümü alın. Trafiğin günlük ve haftalık zirveleri ayrı görülmelidir.

Örneğin 4 vCPU’lu eski bir sistemin gün boyunca ortalama yüzde 12 CPU kullanması, aynı kapasitenin her zaman gerekli olduğu anlamına gelmez. Kısa süreli yüzde 95 zirveler ise tek iş parçacıklı bir uygulamada daha büyük vCPU yerine daha yüksek tek çekirdek performansı gerektirebilir.

Maliyet tablosuna şu kalemleri ekleyin:

• Sanal makine veya konteyner çalışma süresi
• Kalıcı disk ve anlık görüntü kapasitesi
• Yedekleme depolaması ve geri yükleme trafiği
• İnternete ve başka bölgelere giden veri
• Yönetilen veritabanı, izleme ve log saklama ücretleri
• Yönetim için ayrılmış IP, NAT veya yük dengeleyici giderleri

Ay sonunda gelen faturayı beklemek yerine bütçe alarmı kurun. Küçük bir test ortamında kaynakların kapatılmadan bırakılması, gerçek taşıma maliyetini yanlış tahmin ettirir.

Ölçümleri toplayın – Boyutlandırmayı en az 7 günlük gerçek kullanım verisi, büyüme payı ve aylık maliyet sınırı üzerinden yapın.

Veri ve uygulama nasıl hazırlanır?

4. Uygulamayı taşınabilir hâle getirin

Taşıma öncesinde uygulamayı belirli bir sunucunun IP adresine, yerel disk yoluna veya elle düzenlenmiş yapılandırmaya bağımlı olmaktan çıkarın. Ortam değişkenleri, gizli bilgiler, dosya yolları ve servis uç noktaları ayrı bir yapılandırma katmanında tutulmalıdır.

Web uygulamalarında özellikle şu alanları kontrol edin:

• Uygulamanın çalıştığı PHP, Node.js, Python veya Java sürümü
• PHP eklentileri ve işletim sistemi paketleri
• Yüklenen dosyaların bulunduğu dizinler
• Oturumların yerel diskte mi, veritabanında mı tutulduğu
• SMTP, ödeme, harita, CDN ve webhook adresleri
• Arka planda çalışan queue worker ve cron görevleri

WordPress taşınacaksa wp-config.php içindeki veritabanı bilgileri, dosya izinleri, medya dizini ve kalıcı bağlantılar ayrıca test edilmelidir. VPS’te WordPress Kurulumu: Adım Adım Rehber, temiz bir hedef ortam oluştururken temel servis sırasını kontrol etmek için kullanılabilir. Veritabanı bağlantısı taşımadan sonra bozulursa WordPress Veritabanı Bağlantı Hatası Nasıl Çözülür? başlığındaki bağlantı, kimlik doğrulama ve servis kontrolleri yol gösterir.

Gizli anahtarları Git deposuna koymayın. Taşıma sırasında geçici bir dosyaya yazıldıysa işlem bitince silin, erişim izinlerini 600 ile sınırlandırın ve mümkünse anahtarları döndürün.

5. Veri taşıma yöntemini seçin

Statik dosyalarda rsync, veritabanlarında uygulamaya uygun dışa aktarma veya replikasyon yöntemi kullanılabilir. Büyük bir MySQL veritabanını doğrudan web sunucusundan sıkıştırarak taşımak, üretim trafiğiyle aynı disk ve CPU kaynaklarını paylaşacağı için dikkatle zamanlanmalıdır.

rsync -aHAX --numeric-ids --info=progress2 \
  /srv/www/ hedef-sunucu:/srv/www/

-a dosya özniteliklerini ve dizin yapısını korur; -HAX sabit bağları, ACL ve extended attribute bilgilerini de taşımaya çalışır. Hedef dosya sisteminin bu özellikleri desteklediğini doğrulayın. İlk kopyadan sonra yalnızca değişen dosyaları taşıyan ikinci bir rsync çalıştırmak kesim süresini azaltır.

MySQL için örnek bir mantıksal aktarım:

mysqldump --single-transaction --routines --triggers \
  --databases uygulama_db | gzip > uygulama_db.sql.gz
sha256sum uygulama_db.sql.gz

--single-transaction, InnoDB tablolarında tabloyu uzun süre kilitlemeden tutarlı bir görüntü almayı sağlar; tablo motorları ve yazma davranışı yine kontrol edilmelidir. Karma bir tabloda yalnızca bu seçeneğe güvenmeyin. Üretilen SHA-256 özeti, dosyanın taşıma sırasında değişip değişmediğini karşılaştırmak içindir.

Dosya kopyalamak yedek almakla aynı şey değildir. Eski ortamı hemen silmeyin; geri dönüş kararı verilene kadar erişilebilir ve değişikliklerden korunmuş bir kopya bırakın.

Prova yapın – Veriyi en az bir kez hedef ortama taşıyın, dosya sayısını, boyutları, checksum değerlerini ve veritabanı kayıt sayılarını karşılaştırın.

DNS ve ağ geçişi nasıl planlanır?

6. Ağ topolojisini ve güvenlik kurallarını kurun

Hedef ortamda yönetim, uygulama, veritabanı ve yedekleme trafiğini mümkün olduğunca ayırın. Veritabanı portunu internete açmak yerine yalnızca uygulama katmanının özel ağ adreslerinden erişmesine izin verin. SSH için TCP 22 kullanılıyorsa kaynak IP’leri sınırlandırın; port numarasını değiştirmek tek başına güvenlik politikası değildir.

CIDR hesabında yapılan küçük bir hata geniş bir ağı açabilir. CIDR Nedir? IP Aralığı Hesaplama Rehberi, /32 ile tek bir IPv4 adresini, /24 ile 256 adreslik bir aralığı ayırırken gereken temel hesabı açıklar.

Güvenlik grubu veya firewall kurallarını önce varsayılan reddetme yaklaşımıyla oluşturun. Uygulama sağlığı için gereken HTTP 80 ve HTTPS 443 portlarını, yönetim erişimini ve izleme ajanının bağlantılarını tek tek belgeleyin. Bulut kontrol panelindeki kural ile işletim sistemi içindeki nftables veya ufw kurallarının birlikte çalıştığını test edin.

7. DNS TTL değerini ve kesim saatini yönetin

Taşımadan 24-48 saat önce ilgili DNS kayıtlarının TTL değerini düşürmek, resolver önbelleklerindeki eski adreslerin daha kısa süre tutulmasına yardım eder. Bu işlem anında geçiş garantisi vermez; bazı istemciler, uygulama içi DNS önbellekleri veya sağlayıcı politikaları farklı süreler uygulayabilir.

Önce hedef IP’yi doğrudan test edin. Ardından DNS kayıtlarını karşılaştırın:

dig +short eski-alanadi.example A
dig +short yeni-alanadi.example A
curl --resolve site.example:443:YENI_IP https://site.example/ -I

curl --resolve, DNS’i değiştirmeden belirli bir IP üzerinden HTTP isteği göndermenizi sağlar. TLS sertifikasının alan adıyla eşleştiğini ve uygulamanın doğru sanal host’u seçtiğini bu testte görebilirsiniz.

DNS değişikliğinden önce değiştirilecek kayıtların listesini, eski ve yeni değerlerini, değişiklik saatini ve geri dönüş değerini yazın. Alan adı taşıma sırasında 301 yönlendirmeleri de kontrol edilmelidir; 301 Yönlendirme Nedir? SEO İçin Kullanım Rehberi bu kontrolün HTTP katmanındaki etkisini açıklar.

DNS planını yazılı hâle getirin – Her kaydın eski değeri, yeni değeri, TTL’si, değişiklik sorumlusu ve geri dönüş değeri hazır olmadan kesime geçmeyin.

Test ortamında neleri doğrulamalısınız?

8. Fonksiyon, performans ve güvenlik testlerini çalıştırın

Test ortamı yalnızca ana sayfanın açıldığını göstermemelidir. Giriş, çıkış, parola sıfırlama, dosya yükleme, ödeme veya webhook akışları, arka plan görevleri ve yönetim ekranları gerçek kullanım senaryolarıyla denenmelidir.

Veritabanı taşımasında kayıt sayısını ve kritik örnekleri karşılaştırın. Dosya taşımasında eksik medya, bozuk sembolik bağ ve yanlış sahiplik arayın. Linux’ta şu kontroller başlangıç için kullanılabilir:

find /srv/www -type f | wc -l
find /srv/www -type l -ls
stat -c '%U:%G %a %n' /srv/www/site/.env
curl -fsS https://test.site.example/health

Son komut HTTP hata kodunda veya bağlantı probleminde sıfır olmayan çıkış kodu üretir. Sağlık uç noktası veritabanı gibi bağımlılıkları gerçekten kontrol etmiyorsa yalnızca web sunucusunun çalıştığını kanıtlar.

Performans ölçümünde yalnızca TTFB değerini kovalamayın. Uygulama sorguları, disk gecikmesi, PHP worker sayısı, cache isabet oranı ve dış API yanıtları birlikte değerlendirilmelidir. Cache kurulmadan milisaniye tartışmak, yakıt göstergesi çalışmayan bir araçta lastik basıncını konuşmaya benzer.

Yedekten geri dönüş provası da testin parçasıdır. Yedek arşivinin var olması yeterli değildir; yeni ortamda geri yüklenebildiği, uygulamanın açıldığı ve kritik verilerin okunabildiği gösterilmelidir.

Kesim günü nasıl ilerlemeli?

9. Değişiklikleri dondurun ve son senkronizasyonu yapın

Kesimden önce bir bakım penceresi belirleyin. Uygulama dağıtımlarını, veritabanı şemasını ve içerik değişikliklerini bu pencere boyunca durdurun. Kullanıcıya gösterilecek bakım mesajı, beklenen süre ve destek kanalı önceden hazır olsun.

İlk veri kopyasından sonra son bir rsync ve veritabanı aktarımı yapın. Veritabanı yazmalarını durdurmadan alınan son kopya, kabul edilebilir veri kaybı süresiyle uyumlu değilse uygulamayı kısa süreli bakım moduna alın veya replikasyon kullanın.

Kesim sırası genellikle şöyle çalışır:

1. Bakım modunu etkinleştirin ve yeni yazmaları durdurun.
2. Son dosya ve veritabanı senkronizasyonunu tamamlayın.
3. Hedef ortamda servisleri ve worker süreçlerini başlatın.
4. Uygulamayı curl --resolve ve gerçek alan adıyla test edin.
5. DNS A, AAAA, CNAME ve gerekli MX kayıtlarını güncelleyin.
6. Logları, hata oranını, trafik akışını ve iş kuyruklarını izleyin.

Eski sunucuda cron görevlerini kapatmayı unutmayın. Aksi hâlde iki ortam aynı e-postayı gönderebilir, iki kez fatura kesebilir veya aynı kuyruğu paralel tüketebilir.

10. Doğrulama ve geri dönüş eşiğini belirleyin

Kesimden sonra yalnızca sitenin açılmasına bakmayın. HTTP 5xx oranı, oturum açma başarısı, ödeme veya webhook sonuçları, kuyruk uzunluğu, veritabanı bağlantı sayısı, disk kullanımı ve dış servis hataları izlenmelidir.

Geri dönüş kararı önceden sayısallaştırılmalıdır. Örneğin 15 dakika boyunca yüzde 5’in üzerinde 5xx oranı, kritik ödeme akışının çalışmaması veya veritabanı yazma hatalarının tekrarlanması geri dönüş tetikleyicisi olabilir. Bu eşikler her uygulamanın normal trafiğine göre belirlenir; rastgele bir sayı seçmek izleme yapmaktan daha iyi değildir.

Eski ortamı hemen silmeyin. DNS önbellekleri, unutulmuş webhook’lar veya geç fark edilen veri tutarsızlıkları için belirlenmiş bir bekleme süresi bırakın. Süre dolduğunda erişim anahtarlarını iptal edin, eski IP’leri firewall’da kapatın ve hassas diskleri güvenli biçimde imha edin.

Geri dönüş eşiğini uygulayın – Kesim başlamadan önce ölçülebilir hata sınırlarını, karar vericiyi ve eski ortama dönüş adımlarını onaylayın.

Buluta geçiş sonrasında hangi kontroller sürdürülmeli?

Taşıma tamamlandıktan sonra iş bitmez. İlk 24 saat yoğun izleme, ilk hafta maliyet ve performans incelemesi, ilk ay ise mimari değerlendirme yapılmalıdır. İzleme alarmları yalnızca CPU’ya bağlanmamalı; disk doluluğu, inode kullanımı, sertifika süresi, yedekleme sonucu, HTTP 5xx oranı ve veritabanı replikasyon gecikmesi de takip edilmelidir.

IAM tarafında geçici taşıma hesaplarını kapatın, kullanılmayan güvenlik grubu kurallarını kaldırın ve yönetici erişimini çok faktörlü kimlik doğrulamayla sınırlandırın. Loglarda kişisel veya gizli veriler bulunuyorsa saklama süresini ve erişim yetkilerini ayrıca gözden geçirin.

İlk fatura geldiğinde yalnızca toplam tutarı değil, veri çıkışı, disk anlık görüntüleri, boşta kalan IP’ler ve sürekli çalışan test kaynaklarını inceleyin. Buluta geçişin teknik olarak başarılı olması, mimarinin gereğinden pahalı veya yönetilmesi zor olmadığı anlamına gelmez.

Taşıma dokümantasyonunu güncelleyin: yeni IP adresleri, DNS kayıtları, servis sahipleri, geri yükleme komutları, alarm eşikleri ve acil durum iletişim bilgileri tek bir yerde bulunsun. Dokümanın son test tarihi de yazılmalıdır; altı ay önce çalışmış bir prosedür bugün güvenilir sayılmaz.

Taşıma Penceresinden Önce Kontrol Edin

• Mevcut sunucu, servis, port, cron ve dış bağımlılık envanterini tamamlayın.
• Hedef kaynakları, ağ segmentlerini, firewall kurallarını ve aylık bütçe sınırını onaylayın.
• Dosya ve veritabanı aktarımını test ortamında çalıştırıp bütünlük kontrollerini tamamlayın.
• Gizli anahtarları, servis hesaplarını ve geçici erişimleri güvenli biçimde yönetin.
• DNS kayıtlarının eski ve yeni değerlerini, TTL sürelerini ve geri dönüş planını yazın.
• Kesim sırasında bakım modunu, son senkronizasyonu ve doğrulama adımlarını uygulayın.
• Hata eşiklerini izleyin, eski ortamı geri dönüş süresi boyunca koruyun.

Buluta geçiş planı yaparken yalnızca sağlayıcı ve taşıma adımlarını değil, iş yükünüz için hangi altyapının daha uygun olduğunu da değerlendirmek gerekir. Bu noktada [Bare Metal Sunucu ile VPS Arasındaki Teknik Farklar] rehberim, performans, izolasyon, ölçekleme ve bakım yükü açısından doğru seçimi yapmanıza yardımcı olabilir.

Buluta geçiş planını tamamladıktan sonra maliyetleri kontrol altında tutmak için FinOps nedir ve nasıl uygulanır sorularına da yanıt vermek gerekir. Ben, ekiplerin harcamaları düzenli izlemesi ve kaynak kullanımını iş değeriyle birlikte değerlendirmesi için bu rehberdeki yaklaşımı özellikle faydalı buluyorum.

Bulut sağlayıcısı seçerken yalnızca fiyat ve teknik özelliklere değil, güvenlik kontrollerinin bağımsız olarak nasıl değerlendirildiğine de bakıyorum. Bu noktada, hizmet sağlayıcıların güvenlik ve uyum süreçlerini anlamak için [SOC 2 Nedir? Güvenlik ve Uyum Rehberi] yazımıza göz atabilirsiniz.

Sunucu taşıma planına başlamadan önce uygulamanızın işlemci mimarisiyle uyumunu da kontrol etmenizi öneririm. Karar verirken yardımcı olması için [ARM ve x86 VPS Farkı: Hangisini Seçmelisiniz?] rehberime göz atabilirsiniz.

Sık Sorulan Sorular

Kaynaklar

• Docker Docs – Container Images and Packages — docs.docker.com
• MySQL 8.0 Reference Manual – mysqldump — dev.mysql.com
• IETF RFC 1035 – Domain Names — datatracker.ietf.org