İletişim
Services

Services Veritabanı Yedekleme: Anope ve Atheme Kayıtlarını Korumak

· 5 dk okuma

İçindekiler
  1. Veritabanı Nerede?
  2. Yedeklenmesi Gereken Dosyalar
  3. 1. Veritabanını Diske Yazdırmak
  4. 2. Yerleşik Yedekler
  5. 3. Otomatik Yedekleme
  6. 4. Şifreleme
  7. 5. Sunucu Dışına Kopyalama
  8. 6. Geri Yükleme
  9. 7. Geri Yüklemeyi Test Etmek
  10. Yükseltme Öncesi Yedek
  11. Sık Yapılan Hatalar
  12. Gerçek Bir Senaryo
  13. Yedekleme Sorumluluğunu Paylaşmak
  14. Sonuç

Bir IRC ağının services veritabanı, o ağın hafızasıdır. Yıllar içinde kaydedilmiş binlerce nick, yüzlerce kanal, özenle oluşturulmuş erişim listeleri, AKICK kayıtları, vhost'lar ve notlar bu veritabanında saklanır. Bir disk arızası, yanlış bir komut veya bir güvenlik ihlali bu birikimi bir anda yok edebilir. Kullanıcılar nicklerini, kanal sahipleri kanallarını kaybeder ve ağ ciddi bir güven krizine girer. Services veritabanı yedekleme, bu senaryoyu önlemenin tek güvenilir yoludur.

Veritabanı Nerede?

Anope varsayılan olarak kayıtları, kurulum klasöründeki veri dizininde tek bir düz dosyada tutar. Bu dosyanın adı ve yeri services.conf'taki veritabanı modülü ayarlarında belirtilir. SQL veritabanı modülü kullanıyorsanız kayıtlar MySQL veya SQLite gibi bir veritabanında bulunur.

Atheme de kayıtları varsayılan olarak düz metin tabanlı bir dosyada tutar. Dosyanın yeri atheme.conf'ta belirtilir ve genellikle kurulum klasörünün veri dizinindedir.

Her iki yazılım da veritabanını bellekte tutar ve belirli aralıklarla diske yazar. Bu, diskteki dosyanın her zaman en güncel durumu yansıtmadığı anlamına gelir. Yedek almadan önce veritabanını diske yazdırmak önemlidir.

Yedeklenmesi Gereken Dosyalar

DosyaÖnemi
Veritabanı dosyası veya SQL dökümüKritik: bütün kayıtlar
Yapılandırma dosyalarıÇok yüksek: services'i yeniden kurmak için
TLS sertifika ve anahtar dosyalarıYüksek
Üçüncü parti modüller ve özel değişikliklerOrta-yüksek
Log dosyalarıİhtiyaca bağlı

1. Veritabanını Diske Yazdırmak

Yedek almadan hemen önce services'in bellekteki verileri diske yazmasını sağlayın:

/os UPDATE

Bu komut Anope'ta veritabanını hemen kaydeder. Atheme'de de benzer bir komut veya sinyal yöntemi bulunur. Otomatik yedekleme betiklerinde bu adımı atlamamak için services'in kendi kaydetme aralığını kısa tutmak veya yedeği bir kaydetme işleminden hemen sonraya planlamak iyi bir yöntemdir. OperServ komutları için OperServ komutları yazımıza bakın.

2. Yerleşik Yedekler

Hem Anope hem de Atheme, veritabanını kaydederken önceki sürümlerin yedeğini tutma seçeneği sunar. Anope'ta yapılandırmada kaç günlük yedek tutulacağı belirlenebilir. Bu yerleşik yedekler, yanlış bir işlemi birkaç saat sonra fark ettiğinizde hızlı geri dönüş için kullanışlıdır. Ancak aynı sunucuda durdukları için disk arızasına veya sunucunun ele geçirilmesine karşı koruma sağlamazlar.

3. Otomatik Yedekleme

Crontab ile günlük bir yedekleme işi tanımlayın:

15 4 * * * tar czf ~/yedek/services-$(date +\%F).tar.gz -C ~ services/data services/conf

Bu satır her gece veri ve yapılandırma klasörlerini tarihli bir arşive sıkıştırır. Klasör adlarını kendi kurulumunuza göre düzenleyin. SQL veritabanı kullanıyorsanız veritabanının kendi döküm aracıyla ayrı bir döküm alın. Eski yedekleri belirli bir süreden sonra silen bir temizlik komutu da ekleyin.

4. Şifreleme

Services veritabanı hassas bilgiler içerir: e-posta adresleri, parola özetleri, sertifika parmak izleri, kullanıcıların son görülme bilgileri ve notları. Güçlü algoritmalarla özetlenmiş parolalar bile, zayıf parolalar için kaba kuvvet saldırılarına açık olabilir. Bu yüzden yedekler sunucudan çıkmadan önce şifrelenmelidir. Simetrik veya açık anahtarlı şifreleme araçlarıyla arşivi şifreleyebilirsiniz. Açık anahtarlı şifreleme, yedekleme sunucusunda şifre çözme anahtarının bulunmamasını sağladığı için daha güvenlidir.

5. Sunucu Dışına Kopyalama

Yedek, orijinalden farklı bir yerde durmalıdır:

Mümkünse yedekleri en az iki farklı yerde tutun. Yedeklere erişimi olan kişilerin sayısını da sınırlı tutun.

6. Geri Yükleme

Bir gün yedeğe ihtiyaç duyduğunuzda paniğe kapılmadan şu adımları izleyin:

  1. Services'i durdurun. Çalışırken dosyayı değiştirirseniz services kapanırken bellekteki veriyi yeniden yazabilir.
  2. Mevcut veritabanını kenara alın. Silmeyin; incelemek gerekebilir.
  3. Yedeği açın ve veritabanı dosyasını yerine kopyalayın. SQL kullanıyorsanız dökümü veritabanına geri yükleyin.
  4. Dosya izinlerini kontrol edin. Dosyalar services kullanıcısına ait olmalı ve başkaları tarafından okunamamalıdır.
  5. Services'i başlatın ve birkaç nick ile kanalın kayıtlarını kontrol edin.
  6. Kullanıcıları bilgilendirin. Yedek ile geri yükleme arasındaki dönemde yapılan kayıtlar kaybolmuş olabilir.

7. Geri Yüklemeyi Test Etmek

Hiç test edilmemiş bir yedek, gerçekten var olduğundan emin olamayacağınız bir yedektir. Birkaç ayda bir yedeği ayrı bir test ortamına geri yükleyin ve services'in sorunsuz açıldığını doğrulayın. Bu tatbikat, gerçek bir krizde ne yapacağınızı bilmenizi sağlar ve yedekleme sürecindeki eksiklikleri önceden ortaya çıkarır.

Yükseltme Öncesi Yedek

Services yazılımını yükseltmeden önce mutlaka tam bir yedek alın. Yeni sürümler veritabanı biçimini değiştirebilir ve bu dönüşüm geri alınamayabilir. Yükseltme başarısız olursa eski sürüme ve eski veritabanına dönebilmek için bu yedek hayati önem taşır.

Sık Yapılan Hatalar

En sık yapılan hata, yedeklerin aynı sunucuda tutulmasıdır. İkincisi, yedekleme betiğinin sessizce başarısız olması ve bunun aylarca fark edilmemesidir; yedekleme işinin sonucunu düzenli olarak kontrol edin veya başarısız olduğunda bildirim gönderin. Üçüncüsü ise şifrelenmemiş yedeklerin paylaşılan alanlarda tutulmasıdır. Son olarak, veritabanını diske yazdırmadan alınan yedekler son birkaç saatin değişikliklerini içermeyebilir.

Gerçek Bir Senaryo

Bir ağın services sunucusunun diski bir gece arızalanıyor. Neyse ki ağ yöneticileri her gece şifreli yedekleri başka bir sunucuya kopyalıyor. Yeni bir sunucu hazırlanıyor, services yazılımı kuruluyor, yapılandırma dosyaları ve önceki gecenin veritabanı yedeği geri yükleniyor. Services birkaç saat içinde ağa geri dönüyor. Kayıp, yalnızca son yedek ile arıza arasındaki birkaç saatte yapılan bir avuç yeni kayıttan ibaret kalıyor. Yöneticiler kullanıcılara durumu açıklayan bir duyuru yapıyor ve o birkaç kullanıcıdan kayıtlarını yenilemelerini rica ediyor.

Yedekleme Sorumluluğunu Paylaşmak

Yedekleme işini tek bir kişiye bağlamak riskli bir tercihtir. O kişi topluluktan ayrılırsa veya ulaşılamaz hâle gelirse yedeklere kimse erişemez. Bu yüzden ağ yönetim ekibinde en az iki kişinin yedeklere erişimi ve geri yükleme sürecini bilmesi gerekir. Yedeklerin nerede tutulduğu, nasıl şifrelendiği ve nasıl geri yükleneceği kısa bir belgede yazılı olsun; bu belge de yedeklerin yanında değil, ekibin ulaşabileceği ayrı bir yerde dursun.

Sonuç

Services veritabanı, ağınızın en değerli varlığıdır. Yedek almadan önce veritabanını diske yazdırın, her gün otomatik yedek alın, yedekleri şifreleyip sunucu dışına çıkarın ve geri yükleme sürecini düzenli olarak test edin. Atheme'nin kullanıcı grupları özelliğini tanımak için sıradaki rehberimiz Atheme GroupServ.

IRC sorunun mu var? Kanalda birlikte çözelim.

💬 Kanala Bağlan

Sıkça Sorulan Sorular

Services veritabanı kaybolursa ne olur?

Bütün nick ve kanal kayıtları, erişim listeleri, notlar ve vhost'lar kaybolur. Kullanıcıların her şeyi yeniden kaydetmesi gerekir.

Yedeği ne sıklıkla almalıyım?

Kayıtların ne kadar hızlı değiştiğine bağlıdır. Aktif ağlarda en az günlük yedek önerilir.

Yedekler neden şifrelenmeli?

Veritabanı e-posta adresleri, parola özetleri ve sertifika parmak izleri gibi hassas bilgiler içerir. Şifrelenmemiş bir yedek sızdırıldığında bu bilgiler açığa çıkar.