Sunucu işletim sistemini yeniden kurma: öncesi ve sonrası kontrol listesi

Sunucu açılmıyor ya da açılıyor ama o kadar kirli ve dağınık ki onarmak yeniden kurmaktan daha pahalıya geliyor. İşletim sistemini sıfırdan kurmaya karar verdiniz. Reinstall düğmesine basmadan önce şunu bilin: bu işin en büyük riski kurulumun kendisi değil; kaydetmeyi unuttuğunuz şeyler ve sonradan yeniden oluşturmayı hatırlamadığınız şeylerdir.

İşletim sistemini yeniden kurmadan önce: gerçekte ne yedeklenmeli

Site dosyalarını herkes hatırlar. Genellikle geride kalan şey, /var/www dışında yaşayan ve kimsenin "veri" olarak görmediği şeylerdir.

• Yapısı ve verisiyle veritabanları. Kullanıcıları, grant'ları ve trigger'ları kaybederseniz basit bir mysqldump yeterli olmaz. En azından şunu çalıştırın: mysqldump --single-transaction --routines --triggers --events -u root -p --all-databases > all.sql. PostgreSQL için karşılığı pg_dumpall -U postgres > all.sql'dir.
• SSH anahtarları. /root/.ssh ve /home/*/.ssh klasörlerini tamamen alın. Host anahtarını (/etc/ssh/ssh_host_*) saklamazsanız, kurulumdan sonra tüm istemciler REMOTE HOST IDENTIFICATION HAS CHANGED uyarısı alır ve ilgili satırı known_hosts'tan silmeleri gerekir.
• SSL sertifikaları. Let's Encrypt kullanıyorsanız yeniden oluşturmak kolaydır. Satın alınmış bir sertifikanız varsa .key ve .crt dosyalarını alın; yeniden düzenleme maliyet ve zaman gerektirir.
• Cron'lar ve timer'lar. crontab -l -u root çıktısı ve /etc/cron.d/ ile /etc/systemd/system/*.timer içeriği. Bunları kimse yedeklemez çünkü "veri" değil, "ayar"dırlar.
• Servis yapılandırmaları. /etc/nginx, /etc/apache2, /etc/php, /etc/postfix, /etc/fail2ban. Sıfırdan yazsanız bile, önceki sürümü görmek yarım saat kazandırır.
• Standart yol dışındaki dosyalar. Kendi elinizle bir yere koyduğunuz her şey: yedekleme script'leri, env dosyaları, yolunu kodda hardcode ettiğiniz yüklenmiş veriler.

Unuttuğunuz şeyleri bulmanın hızlı bir yolu: kurulumdan önce du -xh --max-depth=2 / | sort -h | tail -40 çıktısını alın ve 1 gigabaytı aşan her yolda bir durun. Eğer ona dair net bir açıklamanız yoksa, muhtemelen sonradan eksikliğini çekeceğiniz şey odur.

Sunucuya erişimi kaybettiyseniz

Sunucu boot etmediğinde, olağan yol panelden sunucuyu rescue modunda başlatıp diski mount etmektir. Bu yol sizin için yeniyse, Sunucuyu yeniden kurma ve rescue moduyla çalışma; erişimi kaybettiğinizde verileri kurtarma kılavuzu bu işi adım adım anlatır. Pratikte sık karşılaştığım nokta: rescue modunda ana disk genellikle /dev/sda1 veya /dev/vda1 üzerindedir ama her zaman böyle değildir. Önce lsblk -f çalıştırın, sonra mount edin.

Kurulumdan sonra yeniden ihtiyaç duyacağınız ayarlar

En çok zamanın harcandığı yer burasıdır, çünkü yeni kurulmuş sunucu teknik olarak sağlıklıdır ama işlevsel olarak henüz eski sunucu değildir.

Her şeyden önce temel güvenlik

İş sırası önemlidir. Önce root olmayan bir kullanıcı oluşturun, sonra parolayla root girişini kapatın, sonra SSH portunu değiştirin. Sırayı tersine çevirir ve iş ortasında bağlantınız kesilirse dışarıda kalabilirsiniz. sshd_config'in tam seçenekleri ve hangilerinin gerçekten değiştirmeye değer olduğu SSH yapılandırması: sshd_config'te önemli güvenlik seçenekleri yazısında yer alıyor. En azından yapmanız gerekenler: PermitRootLogin prohibit-password ve PasswordAuthentication no.

Sonrasında güvenlik duvarı. Her zaman işe yarayan basit kural: Yaygın servis portları ve açık olmaması gereken portlar referansı listesinde olmayan her port kapalı olmalıdır. Bir ss -tulpn çalıştırın ve yalnızca SSH ile web sunucusunun açık olduğunu varsaymak yerine gerçekte neyin dinlediğini görün.

Servisler ve bağımlılıkları

Özel bir servisiniz varsa, unit dosyasını yedekten geri getirin ve systemctl daemon-reload çalıştırın. Yeniden kurulumdan sonra yaygın hata, active (running) olan ama çalışmayan bir servistir; çünkü After= ve Requires= doğru ayarlanmamış ve veritabanından önce ayağa kalkmıştır. Bu bölümlerin ayrıntıları systemd'de unit dosyası: bölümler, restart ve bağımlılık yazısında açıklanmıştır. Hızlı hata ayıklama için: systemctl status myservice ve ardından journalctl -u myservice -n 50 --no-pager.

Dağıtım seçimi, bu sefer doğru seçmek istiyorsanız

Yeniden kurulum, yalnızca "hep olduğu için" kullandığınız dağıtımdan uzaklaşmak için iyi bir fırsattır. Ekibiniz apt ile daha rahatsa, Debian en kararlı seçenektir. Daha yeni kernel ve paket sürümlerine ihtiyacınız varsa, Ubuntu LTS daha iyi bir denge sunar. Daha pratik karşılaştırmayı Sunucu Linux dağıtımı seçimi: pratik ve lafı uzatmayan rehber yazısında görebilirsiniz. Benim tavsiyem: sunucu çalışıyorsa ve sorun yalnızca yazılımsalsa, dağıtımı değiştirmeyin. Dağıtımı değiştirmek ile kurtarmayı aynı anda yapmak iki değişkeni birden değiştirir ve hata ayıklamayı zorlaştırır.

Burada hata yapıyorlar

Gördüğüm en yaygın hata şudur: sunucu yöneticisi tam yedek alır, yeniden kurar, yedeği geri yükler ve sonra "her şey yerinde" der. İki gün sonra işlemsel e-postaların gitmediğini fark eder. Nedeni: SPF, DKIM ve DMARC gibi DNS kayıtları sunucuda değil, harici DNS panelindeydi ve kimse onlara dokunmamıştı. Ama DKIM özel anahtarı sunucudaydı ve yeniden kurulumla yok oldu. Şimdi imza, DNS'te yayınlanan kayıtla uyuşmuyor ve alıcılar e-postayı reddediyor. Belirtisi de sunucu loglarınızda değil; alıcıların spam kutusunda.

İkinci hata daha incedir: /etc'yi yedekten tamamen geri yüklemek. Bu cezbedicidir çünkü hızlıdır, ama önceki dağıtım sürümüne ait yapılandırmaları yeni sürümün üzerine oturtur. Sonuç, açılan ama tuhaf uyarılarla çalışan bir servis ya da yeni sürümde binary yolu değiştiği için hiç başlamayan bir servistir. Yapılandırmaları elle ve seçerek geri yükleyin, hepsini birden değil.

Kurulumdan sonra bunları kontrol edin

1. uptime ve free -m çıktısına bakın. Kurulumdan sonra ve siteyi geri yüklemeden önce yük anormalse, sorun zaten vardı ve yeniden kurulum onu çözmedi.
2. Her servisi systemctl is-enabled ile kontrol edin ki reboot sonrası kendi kendine ayağa kalksın. Şu an running olan ama enabled olmayan bir servis, ilk reboot'ta sizi şaşırtır.
3. Gerçek bir reboot yapın ve açıldıktan sonra her şeyi yeniden test edin. Bağımlılıkların doğru sıralandığından emin olmanın tek yolu budur.
4. İlk 24 saat boyunca logları gözlem altında tutun. Yük yükselirse, Sunucuda yüksek yükün nedenini teşhis etme; pratik ve adım adım rehber iyi bir başlangıç noktasıdır.

Kabul etmeniz gereken gerçek bir maliyet var: işletim sistemini yeniden kurmak, önceden failover mimariniz yoksa sıfıra indirmenin hiçbir yolu olmayan bir downtime penceresi oluşturur. Sitenizin katı bir SLA'sı varsa, doğru iş önce yeni sunucuyu mevcut sunucunun yanında ayağa kaldırmak, servisi taşımak ve sonra eski sunucuyu silmektir. Sanal veya bulut sunucunuz varsa bu pratikte downtime olmadan mümkündür; tek düğümlü özel sunucuda ise değil.

Ve sunucunuz yalnızca düşük trafikli küçük bir siteyse, bazen doğru cevap yeniden kurmak değildir. Sorun belirli bir servisteyse, onu onarın. Yeniden kurulum, sistemin sıfırdan temizlemekten daha pahalıya gelecek kadar kirli veya dağınık olduğu durum içindir. Küçük siteler için yönetilen bir Linux hosting genellikle tam bir sunucu bakımından daha az zahmetlidir, çünkü güncelleme ve yedekleme gibi işler omuzlarınızdan alınır.

Sık sorulan sorular

İşletim sistemini yeniden kurmak sunucudaki tüm dosyaları siler mi?

Evet, normalde işletim sistemi bölümünün tamamı silinir ve aynı diskteki her şey yok olur. Sunucunun ikinci bir diski varsa ve kurulum sürecinde ona dokunmazsanız, verileri kalır; ama bunu varsaymamalısınız; başlamadan önce hangi diskin silineceğini tam olarak bilin.

Yeniden kurmadan önce her şeyi yedeklediğimi nasıl anlarım?

Pratik bir yol, yedeği başka bir makinede restore edip siteyi ayağa kaldırmaktır. Yedek, silmek istediğiniz sunucunun kendisindeyse, o yedek değildir. En azından veritabanını, SSH anahtarlarını, web sunucusu yapılandırmasını ve cron'ları ayrı olarak başka bir yerde tutun.

Yeniden kurulumdan sonra servisler running olduğu halde site neden açılmıyor?

Genellikle şu üç şeyden biridir: dosya izinleri ve klasör sahipliği yanlıştır, web sunucusu yapılandırması eski bir yola veya PHP sürümüne işaret ediyordur, ya da servis bağımlılık nedeniyle doğru ayağa kalkmamış ve yalnızca görünüşte etkindir. journalctl -u nginx -n 50 ve tail -f /var/log/nginx/error.log ile başlayın.

Yeniden kurmadan işletim sistemini yükseltebilir miyim?

Bazı durumlarda evet, ama yıllarca bakım görmeden güncel kalmış bir sunucuda yerinde yükseltme, temiz kurulumdan daha risklidir. Denemek istiyorsanız, önce tam bir snapshot alın ve geri dönüşün her zaman mümkün olmadığını bilin. Eski sunucular için, yapılandırmaları seçerek geri yükleyerek temiz kurulum daha öngörülebilirdir.