Tek VDS'te Kaç Site Barındırılır? Çoklu Site Kurulumu ve İzolasyon

Paylaşımlı hostingte her site için ayrı bir hesap açıyordunuz, panel geri kalanı hallediyordu. Şimdi elinizde 4 vCPU ve 8 GB RAM'li boş bir Ubuntu VDS'i var, ssh root@... ile içindesiniz ve taşıyacağınız beş siteyi nereye koyacağınıza karar vermeniz gerekiyor. Aklınızdaki ilk soru genellikle şudur: "Bu sunucu kaç site kaldırır?"

Bu soru göründüğü kadar masum değil, çünkü cevabı bir sayı değil. Yanlış cevaplandığında ortaya çıkan tablo hep aynı: beş sitenin hepsi /var/www/html altında, hepsi www-data kullanıcısıyla, hepsi tek bir PHP-FPM havuzunda. İlk üç ay sorunsuz geçiyor. Sonra bir sitenin arama sayfasına gelen bot trafiği tüm PHP işçilerini kilitliyor ve beş site birden 502 veriyor. Ya da bir eklenti açığından yüklenen dosya çalıştırılıyor ve saldırgan aynı kullanıcı olduğu için diğer dört sitenin dosyalarına da yazabiliyor.

Bu rehberde önce "kaç site" sorusunu doğru soruya çevirecek, sonra panelsiz bir çoklu site iskeleti kuracağız: site başına Linux kullanıcısı, site başına PHP-FPM havuzu, ayrı server block'lar, doğru izinler. Ardından asıl belirleyici kısma geçeceğiz: bir sitenin kaynak tüketerek diğerlerini düşürmesini ve ele geçirilen bir sitenin diğerlerine yayılmasını nasıl engellersiniz.

"Bu VDS Kaç Site Kaldırır?" Sorusunun Yanlış Tarafı#

Site sayısı bir kapasite ölçüsü değildir. Günde 40 ziyaretçi alan on tanıtım sitesi 4 GB RAM'li bir sunucuda rahatça durur; aynı sunucuda kampanya dönemindeki tek bir e-ticaret sitesi tüm kaynağı tüketebilir. Aradaki fark site sayısı değil, aynı anda kaç PHP isteğinin işlenmekte olduğudur.

Doğru soru şudur: "Bu sunucu aynı anda kaç PHP işçisi çalıştırabilir ve bunu siteler arasında nasıl paylaştıracağım?" Bunu somut bir bütçeye çevirebilirsiniz:

1. Toplam RAM'den işletim sistemi payını düşün (yaklaşık 500 MB).
2. Veritabanı sunucusunun payını düşün. MySQL/MariaDB varsayılan ayarlarla 400-800 MB, ayarlanmış bir InnoDB buffer pool ile daha fazlasını ister.
3. Nginx, Redis, yedekleme ajanı gibi yardımcı servisler için pay ayırın (200-400 MB).
4. Kalanı, ortalama PHP işçi boyutuna bölün.

8 GB RAM'li bir sunucuda tipik dağılım şöyledir:

Bu 41 sayısı, sunucunun tüm siteler için toplam eşzamanlılık bütçesidir. Beş siteniz varsa bu bütçeyi trafiğe göre paylaştırırsınız: yoğun siteye 16, orta ikisine 8'er, sakin ikisine 4'er işçi. Toplam 40. Kritik nokta şudur: paylaştırma yapmazsanız bütçe yoktur. Tek havuzda çalışan beş site, bir tanesi kilitlendiğinde 41 işçinin tamamını tüketir.

Ortalama işçi boyutunu tahmin etmeyin, ölçün. Sunucu bir süredir çalışıyorsa:

# Çalışan PHP-FPM işçilerinin sayısı ve ortalama gerçek bellek kullanımı
ps --no-headers -o rss,cmd -C php-fpm8.3 \
  | awk '{ sum += $1; n++ } END { printf "%d isci, ortalama %.0f MB\n", n, sum/n/1024 }'

pm.max_children hesabının inceliklerine, ondemand ile dynamic arasındaki farka ve tek havuzun ince ayarına PHP-FPM pool ayarları yazımızda girdik. Burada odak, aynı sunucuda birden çok havuzu yan yana çalıştırmak.

Site Başına Linux Kullanıcısı ve Dizin Düzeni#

Çoklu site kurulumunun tüm izolasyonu tek bir karara dayanır: her site kendi Linux kullanıcısı altında çalışır. Bu karar hem dosya izinlerini, hem hack yayılmasını, hem de kaynak muhasebesini aynı anda çözer.

Her site için giriş yapamayan bir sistem kullanıcısı açın:

# ornek1.com için kullanıcı, ev dizini ve alt klasörler
useradd -r -m -d /home/ornek1 -s /usr/sbin/nologin ornek1
mkdir -p /home/ornek1/{public_html,logs,tmp}
chown -R ornek1:ornek1 /home/ornek1

# Ev dizini: sahibi tam, grup okuma+geçiş, diğer herkes kapalı
chmod 750 /home/ornek1
chmod 700 /home/ornek1/tmp
chmod 750 /home/ornek1/public_html

# Nginx statik dosyaları okuyabilsin diye web sunucusunu site grubuna al
usermod -aG ornek1 www-data

-s /usr/sbin/nologin kritik: bu hesaplar SSH ile giriş yapmaz, yalnızca süreç kimliği olarak var olur. 750 izni ise diğer site kullanıcılarının bu dizine hiç girememesini sağlar — çoklu site izolasyonunun tek satırlık özeti budur.

Ortaya çıkan düzen her sitede aynıdır; bu tekdüzelik yedekleme ve otomasyonu kolaylaştırır:

/home/ornek1/
├── public_html/    # site kökü (root direktifinin göstereceği yer)
├── logs/           # access.log, error.log, php-error.log, fpm-slow.log
└── tmp/            # oturum dosyaları, upload kuyruğu, geçici dosyalar

⚠️ www-data'yı her site grubuna eklemek, Nginx'in tüm sitelerin dosyalarını okuyabilmesi anlamına gelir. Statik dosyalar için bu zaten gerekli ve kabul edilebilir. Ama yapılandırma dosyalarını grup okumasına açık bırakmayın: chmod 600 /home/ornek1/public_html/wp-config.php yapın. O dosyayı okuması gereken tek süreç, dosyanın sahibi olarak çalışan PHP-FPM işçisidir; Nginx'in içeriğine hiç ihtiyacı yoktur. İzin modellerinin genel mantığı için Linux dosya izinleri yazımıza bakabilirsiniz.

Site Başına PHP-FPM Havuzu Nasıl Tanımlanır?#

Havuz dosyaları /etc/php/8.3/fpm/pool.d/ altında yaşar. Dağıtımla gelen www.conf dosyasını kullanmayın; adını www.conf.disabled yapmak devre dışı bırakmaya yeter. Her site kendi dosyasını alır:

; /etc/php/8.3/fpm/pool.d/ornek1.conf
[ornek1]
user = ornek1
group = ornek1

; Her havuz kendi soketini dinler; sahibi web sunucusu olmalı ki Nginx bağlanabilsin
listen = /run/php/php8.3-fpm-ornek1.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Bu sitenin eşzamanlılık payı
pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 20s
pm.max_requests = 500

; Sitenin kendi kaynak ve güvenlik sınırları
php_admin_value[memory_limit] = 256M
php_admin_value[open_basedir] = /home/ornek1/public_html:/home/ornek1/tmp:/usr/share/php
php_admin_value[upload_tmp_dir] = /home/ornek1/tmp
php_admin_value[sys_temp_dir] = /home/ornek1/tmp
php_admin_value[session.save_path] = /home/ornek1/tmp
php_admin_value[error_log] = /home/ornek1/logs/php-error.log
php_admin_flag[log_errors] = on

; Yavaş istekleri site bazında yakala
slowlog = /home/ornek1/logs/fpm-slow.log
request_slowlog_timeout = 5s

Bu dosyada çoklu site için üç satır özellikle önemlidir ve tek site kurulumlarında hiç konuşulmaz:

session.save_path. Varsayılanda tüm PHP oturum dosyaları /var/lib/php/sessions altında toplanır ve dosyalar orada oturum kimliğiyle isimlenir. Beş site aynı dizini paylaşıyorsa, bir sitedeki kod diğer sitelerin oturum dosyalarını listeleyip okuyabilir. Havuzu ayırdınız ama oturumları ayırmadıysanız izolasyon yarım kalır.

open_basedir. PHP'nin dosya işlemlerini listelenen dizinlerle sınırlar. Bir web shell yüklense bile /home/ornek2/public_html/wp-config.php dosyasını file_get_contents ile okuyamaz. Tek başına aşılmaz bir duvar değildir (kabuk çalıştıran fonksiyonlar bunu atlar), ama Linux kullanıcı ayrımıyla birlikte kullanıldığında en yaygın saldırı yolunu kapatır.

sys_temp_dir ve upload_tmp_dir. Yüklenen dosyaların geçici olarak /tmp içine düşmesi, aynı /tmp'yi paylaşan diğer sitelerin bu dosyaları görmesi demektir. Site kendi tmp dizinini kullansın.

Dosyayı yazdıktan sonra yapılandırmayı yükleme öncesi doğrulayın:

php-fpm8.3 -t                 # yapılandırma sözdizimi testi
systemctl reload php8.3-fpm   # kesintisiz yeniden yükleme
systemctl status php8.3-fpm --no-pager | head -20
ls -l /run/php/               # her site için ayrı bir .sock görmelisiniz

Bir havuzda yazım hatası varsa reload başarısız olur ve tüm siteler eski yapılandırmayla çalışmaya devam eder. Ama restart yaparsanız servis hiç kalkmaz ve beş site birden düşer; çoklu site sunucusunda alışkanlığınız reload olsun.

Nginx Server Block Düzeni ve Varsayılan Sunucu Tuzağı#

Her site kendi dosyasını /etc/nginx/sites-available/ altında alır ve sites-enabled içine sembolik bağla etkinleştirilir.

# /etc/nginx/sites-available/ornek1.com
server {
    listen 80;
    listen [::]:80;
    server_name ornek1.com www.ornek1.com;

    root /home/ornek1/public_html;
    index index.php index.html;

    access_log /home/ornek1/logs/access.log;
    error_log  /home/ornek1/logs/error.log warn;

    client_max_body_size 32m;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm-ornek1.sock;
        fastcgi_read_timeout 60s;
    }

    # Gizli dosyalar kapalı, ACME doğrulaması açık
    location ~ /\.(?!well-known) {
        deny all;
    }
}

Buradaki tek kritik satır fastcgi_pass içindeki soket yoludur: server block ile havuz arasındaki bağ tam olarak burada kurulur. Yanlış soketi gösterirseniz site açılır, çalışır ve başka bir sitenin kullanıcısı olarak dosya yazar. Yeni site eklerken en sık yapılan kopyala-yapıştır hatası budur; site eklendikten sonra ps -o user,cmd -C php-fpm8.3 çıktısında doğru kullanıcının göründüğünü doğrulayın.

İkinci tuzak, varsayılan sunucudur. Nginx, Host başlığı hiçbir server_name ile eşleşmeyen bir istek geldiğinde onu ilk tanımlı server block'a verir. Yani sunucunun IP adresine doğrudan bağlanan bir tarayıcı ya da rastgele bir alan adı yönlendiren biri, sizin en değerli sitenizi görebilir. Bunu bir yakalayıcı blokla kapatın:

# /etc/nginx/sites-available/000-default
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;   # bağlantıyı yanıt vermeden kapat
}

Apache tarafında da mantık aynıdır; sadece söz dizimi değişir ve a2ensite ile etkinleştirme yapılır. VirtualHost bloklarının anatomisi ve varsayılan site davranışı için Apache virtual host tanımlama yazısına bakın. Nginx ile PHP-FPM arasındaki fastcgi_pass, soket-TCP tercihi ve zaman aşımı ayarları ise Nginx ve PHP-FPM yapılandırması yazısında ayrıntılı.

Her değişiklikten sonra sırayla:

nginx -t                       # yapılandırma testi
systemctl reload nginx
curl -sI -H 'Host: ornek1.com' http://127.0.0.1/ | head -3

Bir Site Diğerlerini Nasıl Düşürür ve Nasıl Engellenir?#

Havuzları ayırdığınızda en yaygın çöküş senaryosunu zaten çözmüş olursunuz: bir sitenin işçileri tükendiğinde sadece o site 502 verir, komşuları çalışmaya devam eder. pm.max_children artık bir performans ayarı değil, bir duvardır.

Ama iki kaynak hâlâ paylaşılmaya devam eder ve gerçek dünyada asıl acıyı bunlar verir.

Bellek. Havuz başına pm.max_children × memory_limit çarpımı, o sitenin en kötü durum tavanıdır. Tüm tavanları toplayın; sonuç RAM bütçenizi aşıyorsa aşırı taahhüt yapıyorsunuz demektir. Hepsi aynı anda tavana çıkmaz, ama çıktıklarında OOM killer devreye girer ve genelde en büyük süreci — yani MySQL'i — öldürür. Beş sitenin birden veritabanı hatası vermesinin klasik sebebi budur.

CPU. Tüm havuzlar tek bir php8.3-fpm.service altında yaşadığı için, o servise koyacağınız CPUQuota sitelerin tamamını birlikte sınırlar. Site bazında CPU sınırı istiyorsanız, o havuzu ayrı bir systemd servisi olarak çalıştırmanız gerekir:

# /etc/systemd/system/php-fpm-ornek1.service
[Unit]
Description=PHP-FPM (ornek1)
After=network.target

[Service]
Type=notify
ExecStart=/usr/sbin/php-fpm8.3 --nodaemonize --fpm-config /etc/php/8.3/fpm/ornek1/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID

# cgroup sınırları: yalnızca bu siteyi bağlar
CPUQuota=100%
MemoryMax=1200M
TasksMax=96

[Install]
WantedBy=multi-user.target

Bu servisin göstereceği php-fpm.conf dosyası kendi pid ve hata günlüğünü tanımlayıp havuzu dahil eder:

; /etc/php/8.3/fpm/ornek1/php-fpm.conf
[global]
pid = /run/php/php-fpm-ornek1.pid
error_log = /home/ornek1/logs/fpm-master.log
daemonize = no
include = /etc/php/8.3/fpm/ornek1/pool.conf

CPUQuota=100% bir çekirdek demektir; MemoryMax aşıldığında çekirdek yalnızca bu cgroup içindeki süreçleri sonlandırır, yani taşan site kendi kendini keser ve komşularına dokunmaz.

Bu ayrım her sunucuda gerekli değildir; beş sakin site için havuz sınırları fazlasıyla yeterlidir. Ama sitelerden biri müşteri sitesiyse ve kodu üzerinde denetiminiz yoksa, cgroup sınırı "o site beni kaç kez uyandırdı" sorusunu ortadan kaldırır.

Veritabanı tarafını da unutmayın. Site başına ayrı bir MySQL kullanıcısı ve veritabanı açın, ardından bağlantı sayısını kullanıcı bazında sınırlayın:

CREATE DATABASE ornek1_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'ornek1'@'localhost' IDENTIFIED BY 'guclu-parola';
GRANT ALL PRIVILEGES ON ornek1_db.* TO 'ornek1'@'localhost';
ALTER USER 'ornek1'@'localhost' WITH MAX_USER_CONNECTIONS 15;
FLUSH PRIVILEGES;

MAX_USER_CONNECTIONS olmadan, tek bir sitenin kilitlenen sorguları max_connections havuzunu tüketir ve diğer dört site "Too many connections" hatası alır.

Bir Site Hacklendiğinde Yayılmayı Durdurmak#

Çoklu site sunucularında olayların çoğu şöyle başlar: sitelerden birinde güncellenmemiş bir eklenti, bir dosya yükleme açığı, uploads dizinine düşen bir PHP dosyası. Asıl soru bundan sonrasıdır — saldırgan ne kadar ileri gidebilir?

Tek kullanıcı modelinde çok ileri gider. Her şey www-data olarak çalıştığı için yüklenen kabuk, diğer dört sitenin dosyalarına da yazabilir; hepsine aynı anda yönlendirme kodu enjekte eder ve haftalar sonra fark edilir.

Bu rehberdeki modelde ise saldırgan ornek1 kullanıcısıdır ve şu duvarlara çarpar:

Zarar kendi sitesiyle sınırlı kalır. Temizlik tek bir ev dizinini ve tek veritabanını kapsar; diğer dört siteyi karantinaya almanız gerekmez.

Bu duvarları bir kademe daha yükseltmek için havuza tehlikeli fonksiyon kısıtı ekleyebilirsiniz:

php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen

Bunu havuz bazında yapmak, tek bir global php.ini satırıyla yapmaktan daha kullanışlıdır: bir sitenin dağıtım betiği gerçekten proc_open istiyorsa yalnızca o havuzda açarsınız, diğer dördü kapalı kalır.

Son olarak yükleme dizinlerinde PHP çalıştırmayı kapatın — çoklu sitede bu tek satır, yukarıdaki senaryonun başlamasını bile engeller:

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

Site Başına Log, Yedek, SSL ve Cron Ayrımı#

İzolasyonu kurduktan sonra günlük operasyonun da site bazında ayrılması gerekir. Aksi halde tüm siteler tek bir access.log içine yazar ve "hangi site bu trafiği çekti" sorusunu cevaplayamazsınız.

Loglar. Nginx blokları zaten site logs dizinine yazıyor. Döndürme kuralını da site bazında yazın:

# /etc/logrotate.d/site-ornek1
/home/ornek1/logs/*.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    create 0640 ornek1 ornek1
    sharedscripts
    postrotate
        [ -f /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
    endscript
}

create satırındaki sahiplik önemlidir: yeni log dosyası root'a ait olursa PHP-FPM işçisi kendi hata günlüğüne yazamaz hâle gelir ve hatalar sessizce kaybolur. Döndürme mantığının ayrıntısı için logrotate ile log yönetimi yazısına bakın.

SSL. Her alan adı kendi sertifikasını alır. Certbot, Nginx eklentisiyle server block'u kendi günceller:

certbot --nginx -d ornek1.com -d www.ornek1.com
certbot renew --dry-run

Beş siteyi aynı gün tek tek eklerken Let's Encrypt'in haftalık sertifika limitine takılabilirsiniz; sınırlar ve toplu kurulum stratejisi Let's Encrypt ücretsiz SSL yazısında.

Cron. Zamanlanmış görevleri root crontab'ına toplamayın; her site kendi kullanıcısıyla çalışsın:

crontab -u ornek1 -e
# WordPress zamanlayıcısını gerçek cron'a bağla
*/15 * * * * /usr/bin/php8.3 /home/ornek1/public_html/wp-cron.php >/dev/null 2>&1

Kullanıcının kabuğu nologin olsa bile kullanıcı crontab'ı çalışır; cron komutu doğrudan /bin/sh ile yürütür ve giriş kabuğuna bakmaz. Bu ayrım, bir görev sunucuyu yorduğunda ps çıktısında hangi siteye ait olduğunu anında göstermesi açısından değerlidir.

Yedek. Site başına iki parça vardır: ev dizini ve veritabanı. İkisini aynı komut dosyasında toplayın ki bir siteyi geri yüklerken diğerlerine dokunmak zorunda kalmayasınız:

#!/bin/bash
set -euo pipefail
SITE="$1"
DEST="/var/backups/$SITE/$(date +%F)"
mkdir -p "$DEST"

mysqldump --single-transaction --quick "${SITE}_db" | gzip > "$DEST/db.sql.gz"
rsync -a --delete "/home/$SITE/public_html/" "$DEST/files/"

Bu betiği her site için ayrı çağırmak, geri yükleme anında tek siteyi hedeflemenizi sağlar.

Yeni Site Eklerken Kontrol Listesi#

Altıncı siteyi eklerken hafızaya güvenmeyin; atlanan bir adım genelde haftalar sonra fark edilir:

1. Kullanıcı ve dizinleri oluşturun, izinleri 750 yapın, www-data'yı gruba ekleyin.
2. Havuz dosyasını yazın; soket adını, user, session.save_path ve open_basedir satırlarını kopyaladığınız dosyadan değiştirmeyi unutmayın.
3. php-fpm8.3 -t ile doğrulayıp reload edin, /run/php/ altında yeni soketi görün.
4. Server block'u yazın, fastcgi_pass yolunun yeni sokete gittiğini iki kez kontrol edin.
5. nginx -t ve reload; ardından curl -H 'Host: ...' ile yerelden test edin.
6. Veritabanı ve MySQL kullanıcısını açın, MAX_USER_CONNECTIONS verin.
7. Certbot ile sertifikayı alın, renew --dry-run çalıştırın.
8. logrotate kuralını ekleyin, cron görevlerini site kullanıcısına yazın.
9. Yedek betiğine yeni siteyi ekleyin ve bir geri yükleme denemesi yapın.
10. Toplam pm.max_children bütçesini yeniden hesaplayın — yeni site eklerken eski sitelerin payını kısmanız gerekebilir.

Onuncu madde en sık atlananıdır. Havuz eklemek bellek yaratmaz; sadece paylaştırma biçimini değiştirir. Sunucunun bütçesi dolduğunda doğru hamle yeni bir havuz eklemek değil, kapasiteyi büyütmek ya da yükü ikinci bir sunucuya bölmektir.

Sıkça Sorulan Sorular#

2 GB RAM'li bir VDS'te kaç site barındırabilirim?#

Site sayısı yerine eşzamanlılık üzerinden düşünün. 2 GB'ta işletim sistemi ve MySQL'den sonra PHP için yaklaşık 700-900 MB kalır; bu da 90 MB'lık WordPress işçileriyle toplam 8-10 işçi demektir. Bu bütçeyi düşük trafikli üç-dört tanıtım sitesine rahatça bölebilirsiniz. Aynı sunucuya WooCommerce koyarsanız tek site bile bu bütçeyi zorlar.

Her site için ayrı PHP-FPM havuzu şart mı?#

Teknik olarak şart değil, pratikte evet. Tek havuz iki şeyi birden kaybettirir: bir sitenin trafiği tüm işçileri tükettiğinde hepsi birden düşer ve tüm siteler aynı Linux kullanıcısıyla çalıştığı için bir sitedeki açık diğerlerine yayılır. Ayrı havuz, her iki riski de tek yapılandırma dosyasıyla kapatır.

Panel kurmadan çoklu site yönetmek zor değil mi?#

İlk kurulum panelden uzun sürer, sonrası daha kısadır. Yukarıdaki adımlar bir kabuk betiğine dönüştürülebilir ve yeni site eklemek iki dakikaya iner. Panelin gerçek üstünlüğü müşterilere kendi hesaplarını yönetme imkânı vermektir; siteler size aitse panelin tükettiği RAM'i PHP işçilerine ayırmak daha verimlidir.

Sitelerden biri çok yavaşladı, hangisinin suçlu olduğunu nasıl bulurum?#

Havuzlar ayrıysa bu soru zaten kolaydır. ps -o user,rss,cmd -C php-fpm8.3 çıktısı hangi kullanıcının kaç işçi tuttuğunu gösterir. Her havuza slowlog ve request_slowlog_timeout tanımladıysanız, beş saniyeyi aşan isteklerin yığın izini doğrudan o sitenin log dizininde bulursunuz. Ayrıca site bazında access.log sayesinde trafik artışını da ayırt edebilirsiniz.

Aynı sunucuda hem Nginx hem Apache çalıştırabilir miyim?#

Çalıştırabilirsiniz ama ikisi 80 ve 443 portlarını aynı anda dinleyemez. Yaygın kurulum Nginx'i önde ters vekil olarak, Apache'yi arkada 8080 gibi bir portta tutmaktır. Çoklu site senaryosunda bu iki kat yapılandırma bakımı demektir; yalnızca .htaccess bağımlı eski bir uygulamanız varsa tercih edin, aksi halde tek web sunucusunda kalın.

Bir siteyi başka sunucuya taşımak istersem ne yapmam gerekir?#

Bu modelin en büyük getirisi taşınabilirliktir. Bir site tamamen kendi ev dizini, kendi veritabanı, kendi havuz dosyası ve kendi server block'undan ibarettir. Yeni sunucuda kullanıcıyı açar, dizini rsync ile kopyalar, veritabanını içe aktarır ve iki yapılandırma dosyasını taşırsınız. Diğer sitelere hiç dokunmadan tek siteyi ayırabilmek, düzenin doğru kurulduğunun kanıtıdır.