Gerek büyük ölçekli kurumsal altyapılarda gerekse kişisel uygulamalarımızda kolaylıkla yönetilebilir ve izlenebilir bir yedekleme çözümü oluşturmak, kararlı ve herşeyden önce düzenli bir strateji ortaya koymak düşünüldüğü kadar kolay olmasa gerek ki bugün profesyonel veri merkezlerinde dahi elinde USB hard disklerle bir sunucudan diğerine koşan ve saatlerce veri transferinin gerçekleşmesini bekleyen keyifsiz sistem sorumluları görmekteyiz. Bu külfetli süreç için feda edilen zaman ve enerjinin çoğu işletmede pahallı ticari yedekleme çözümlerine yatırım yapmaktansa katlanılacak bir bedel olarak görülüyor olduğunun farkındayım. Diğer bir taraftan yedeğinin alınması gereken verilerin önemi ve değerleri göz önünde bulundurulduğunda manüel ve sadece belirli aralıklarla gerçekleştirilen geleneksel yedekleme modelinin taşıdığı riskler de ortadadır.
Bu uygulamamızda üzerinde FreeBSD kurulu bir sunucu ile yerel ağlarınızdaki istemci ve iş istasyonlarının, veri merkezinizde yer alan sunucularınızın, intranet ve extranetiniz hatta uzak ofis ve veri kurtarma merkezlerinizdeki makinaların yedeklemelerinin otomatik olarak gerçekleştirilmesine yönelik projemi inceliyor olacağız. Özellikle rsync çalışma prensibi ve ilgili algoritmaları sayesinde sadece üzerinde değişiklik gerçekleştirilmiş verilerin transferine dayalı bu çözüm, uzun mesafeler ve kısıtlı bant genişliği kriterlerinden dolayı çok büyük boyutlu verilerin yedeklerinin alınması ya da eşitleme ve senkronizasyonun problem teşkil edebileceği durumlarda dahi düğümler arasında sağlıklı, kararlı ve güvenli bir çözüm olarak kullanılabilir. Çözüm, yedeği alınacak düğümlerin işletim sistemine bağımlı olmayıp Microsoft, unix ve linux tüm sunucu ve istemcileri yedeklemede kullanılabilir. Özellikle çözümde ağırlıklı olarak unix shell programlama tekniklerinin kullanılıyor olması dolayısıyla anlaşılmasının ve uygulanmasının kolay olacağını, uyumsuzluk problemlerinin minimize edilmiş olacağını düşünmekteyim. Uygulamayı hayata geçirdiğimizde tüm yedekleme işlemlerine ilişkin aşağıdaki ekran çıktısında göreceğiniz şekilde otomatik html bilgilendirme mailleri alıyor olacağız.
Rsync sunucusu tarafından gönderilen bilgilendirme e-maili
Başlangıç olarak altyapımızda yedeği alınacak düğümlerin sayısı ve yedeklenecek verilerin miktarı ile orantılı olarak depolamayı gerçekleştirecek olan sunucumuzu ve disk ebatlarını kafi gelecek şekilde seçmemiz, yedeklerin bulundurulacağı FreeBSD disk dilim ve dizinlerini projeye uygun olarak biçimlendirmeniz gerekecektir. Zorunlu olmasa da yedeklerin tutulacağı bu makinanın önemi göz önünde bulundurulduğunda sunucuda disk yedeklemesi yapılması mantıklı olacaktır. Yapılandırmada küçük yapılar için minimal yatırım ile RAID1, büyük yapılar için ise az hacim kaybı ile kafi miktarda güvenlik sunabilecek RAID5 tercih edilebilir. Sonuç olarak sunucu ve disk birimlerinin belirlenmesi stratejisi tamamiyle bu çözümün uygulanacağı altyapıya göre değişkenlik gösteriyor olacaktır.
Uygulamamız çerçevesinde yedeklerimizi /usr dizininde tutacağımızı düşünerek bu dizinin blok hacminin geniş tutulması gerektiğini hatırlatmak isterim. Ancak eğer bu proje için yeni bir donanım tahsis etmeyecek, var olan bir sistemi bu işe ayıracaksanız ve disk dilimlerini yeniden yapılandırma şansınız bulunmayacaksa bu durumda kafi miktarda boş alan bulunan diğer bir dilimi (Örneğin; /var) kullanabilirsiniz. Ancak bu durumda scriptleri ve ön tanımlı değişkenleri bu yönde düzenlemeniz gerekecektir.
Bu projenin ihtiyaç duyacağı ve uygulamaya geçmeden önce FreeBSD ports dizininden yararlanarak kolayca kurabileceğiniz gerekli ek uygulama ve servisler; Bash ve Mutt. Bu paketler sisteminizde yüklü ise devam edebiliriz. Değil ise, ports dizinini güncelleyerek bu paketleri kurunuz.
Ports dizininiz mevcut değilse;
# portsnap fetch # portsnap extract
Ports dizininiz mevcut fakat güncel değil ise;
# portsnap fetch # portsnap update
Daha sonra paketlerin kurulumuna geçebiliriz;
# cd /usr/ports/shells/bash # make all install clean
# cd /usr/ports/mail/mutt # make all install clean
Aşağıdaki linki kullanarak uygulamamıza ilişkin scriptler, şablonlar, yapılanıdırma dosyası ile birlikte kurulumu gerçekleştirecek olan install.sh’i içeren rbs-project-v2.0.tar.gz dosyasını sunucunuzda uygun bir lokasyona download ediniz. “install.sh” scripti, uygulamanın iskeletini oluşturacak örnek yapının kurulumunu ototmatik olarak gerçekleştirecektir. Uygulamadan gerçek anlamda faydalanmaya başlayabilmek için ilgili dizin ve scriptlerde yapınıza göre ufak düzenleme ve değişiklikler yapmanız gerekecektir.
MD5 = 526c1307221509050fe66ab610c40325
SHA256 = a2e12fc15d2936efc0eda49822c57195a0744582dae40c23f2c34f26dddca146
Sıkıştırılmış dosyamızı açalım ve kurulum dizinine girelim;
# tar -xvf rbs-project-v2.0.tar.gz # cd rbs-project-v2.0
Rsync’in, aynı zamanda yedeklere erişim ve geri yükleme amacıyla uygulamamızı destekleyecek FTP servisi ve Samba gibi uygulamaların birlikte kullanacağı “backup” grubununun yaratılması, yapılandırma dosyası içerisinde gireceğiniz değişkenlere tekabül eden parametrelerin ayrıştırılarak gerekli klasör ve alt klasörlerin oluşturulması, şablonların ilgili yerlere yerleştirilmesi gibi işlemleri sizin yerinize gerçekleştirecek ve zaman kazandıracak olan install.sh scriptini çalıştırmadan önce mutlaka kurulum klasörünün ana dizininde bulunan söz konusu variables.inc yapılandırma dosyasını aşağıda değinilecek yönergeler paralelinde düzenleyiniz.
# variables.inc # Sezgin Bayrak, sbayrak@ipsure.com # http://www.ipsure.com (2010) RSYNC_SERVER hostname.yourdomain.com <BEGIN> HOST: host1 DOMAIN: yourdomain.com IP: 192.x.x.1 FOLDER_NAME: HOSTFolders DB_DIR_NAME: AUTOCURRENT FOLDER_MAX_DAY: 10 DB_DIR_MAX_DAY: 5 IMAGE_PATH: http://web.server.com/rsync/img FOLDER_OK_IMAGE: host1-ok.jpg FOLDER_FAILURE_IMAGE: host1-fail.jpg DB_DIR_OK_IMAGE: host1db-ok.jpg DB_DIR_FAILURE_IMAGE: host1db-fail.jpg MAIL_ADDRESS: mailbox@yourdomain.com <END> <BEGIN> HOST: host2 DOMAIN: yourdomain.com IP: 212.x.x.1 FOLDER_NAME: AppFolder DB_DIR_NAME: DBFolder FOLDER_MAX_DAY: 21 DB_DIR_MAX_DAY: 7 IMAGE_PATH: http://web.server.com/rsync/img FOLDER_OK_IMAGE: host2-ok.jpg FOLDER_FAILURE_IMAGE: host2-fail.jpg DB_DIR_OK_IMAGE: host2db-ok.jpg DB_DIR_FAILURE_IMAGE: host2db-fail.jpg MAIL_ADDRESS: rsyncadmin@yourdomain.com <END>
“variables.inc” içerisinde yer alan yapılandırma şablonundaki değişkenleri, bu sunucuya yedeklemek istediğiniz her host için ayrı ayrı ve alt alta yapılandırınız.
Yapılandırma esnasında ilk sütunda bulunan değişken başlıklarını (Ör: IP:) değiştirmeden sadece karşılarında yer alan ifadeleri (Ör: 192.x.x.1) editleyiniz. Bu başlıklar betikler içerisinden çağrılmakta ve belirleyici özellik taşımakta oldukları için değiştirildiklerinde çakışmalar ve ya uyuşmazlıklar meydana gelecektir, uygulama çalışmayabilir.
install.sh betiğini çalıştırdıktan sonra, senkronizasyon ve yedeğinin gerçekleştirileceği ve variables.inc içerisindeki yapılandırma satırlarının ilk değişkeni olarak tanımlanan HOST kaynak makinaları için /usr/backup-sys/agents/, /usr/backup-sys/mail/ ve /usr/backups/ dizinleri altında ilgili yönetim ve depolama klasörlerinin birebir aynı HOST ismiyle yaratıldığından emin olunuz;
/usr/backup-sys/agents/HOST /usr/backup-sys/mail/HOST /usr/backups/HOST
/usr/backups/HOST dizinlerinin birazdan değineceğimiz rsyncd.conf içerisindeki yapılandırmanızda, depolama için tanımlayacağınız yollar olacağına dikkatinizi çekmek isterim!
Örneğin;
/usr/backup-sys/agents/ns1 /usr/backup-sys/mail/ns1 /usr/backups/ns1
FOLDER_NAME: Kaynakta dağınık halde bulunabilecek klasör ve dosyaların senkronizasyondan sonra rsync sunucusunda HOST klasörünün altında hangi alt klasör altında toplanacağını ifade eder. Özetle kaynaktaki çeşitli dosya ve klasörlerin yedeğinin, sunucu üzerinde saklanacağı alandır.
DB_DIR_NAME: Kaynakta alınan veritabanı yedeklerinin rsync sunucusuna transferinden sonra HOST klasörünün altında hangi alt klasör içerisinde bulunacağını ifade eder. Kaynaktan gönderilecek MS SQL, MySQL yedek dosyalarının sunucu üzerinde saklanacağı alandır.
install.sh’i çalıştırdıktan sonra yapılandırmanız doğrultusunda her host için bunların da yaratıldığından emin olunuz;
/usr/backups/HOST/FOLDER_NAME # Depolama için /usr/backups/HOST/DB_DIR_NAME # Depolama için /usr/backup-sys/mail/HOST/FOLDER_NAME # E-mail yönetim scriptleri için /usr/backup-sys/mail/HOST/DB_DIR_NAME # E-mail yönetim scriptleri için
Örneğin;
/usr/backups/websrv-01/AppFolder /usr/backups/websrv-01/AUTOCURRENT /usr/backup-sys/mail/websrv-01/AppFolder /usr/backup-sys/mail/websrv-01/AUTOCURRENT
FOLDER_MAX_DAY değişkeni senkronize edilen klasörün sıkıştırılmış versiyonunun en fazla kaç gün sistemde tutulacağını, DB_DIR_MAX_DAY değişkeni ise transfer edilmiş veritabanı yedeği klasörünün sıkıştırılmış versiyonunun en fazla kaç gün sistemde tutulacağını ifade eder. Yedeği alınan dosyaların önemi, büyüklüğü, rsync sunucunuzun disk alanı ve geçmişe dönük saklama ihtiyaçlarınızı göz önünde bulundurarak bu iki değişken ile ilgili süreyi ayarlayabilirsiniz.
IMAGE_PATH, web sunucusu yapılandırmanıza göre otomatik maillerde kullanılacak imaj ve ikonların çağrılacağı mutlak URL’i ifade eder. FOLDER_OK_IMAGE | FOLDER_FAILURE_IMAGE | DB_DIR_OK_IMAGE | DB_DIR_FAILURE_IMAGE değişkenleri, otomatik mailler içerisinde her bir host ve ya klasörün yedeğinin başarılı/başarısız/kısmen ok. durumlarını yukarıdaki html e-mail ekran çıktısında da görebileceğiniz başlık barları şeklinde ifade eden görselleri temsil eder. Bunları yedeklerini tutacağınız her makina için dilediğiniz şekilde üreterek değiştiriniz. (Referans alabilmeniz için ilgili resimler rbs-project-v2.0/images altına konulmuştur, ilgili web dizinine kopyalayınız.)
Örneğin;
http://www.ipsure.com/rsyncmail/img # /img sonuna "/" koymayınız.
/img içerisine yerleştirdiğiniz görsel dosyalarınızın erişim izinlerini ayarlamayı unutmayınız; (Tipik olarak 644)
-rw-r--r-- 1 ftpuser ftp 23439 Nov 20 02:01 mikrodbfail.jpg -rw-r--r-- 1 ftpuser ftp 23931 Nov 20 02:01 mikrodbok.jpg -rw-r--r-- 1 ftpuser ftp 23269 Nov 20 02:01 mikrofail.jpg -rw-r--r-- 1 ftpuser ftp 24073 Nov 20 02:01 mikrook.jpg
MAIL_ADDRESS değişkeni, ilgili host için otomatik bilgilendirme maillerinin hangi mail adresine gönderileceğini belirler. Birden fazla ilgiliye mail gönderilmesini istiyorsanız buraya tanımlayacağınız e-mail adresini, mail sunucunuzda bir dağıtım listesi olarak ayarlayabilirsiniz.
variables.inc içerisinde yedeğini almak istediğinizi her host için yapılandırmayı gerçekleştirdiyseniz, artık aynı dizinde bulunan install.sh’i çalıştırabiliriz;
# ./install.sh
RSYNC KURULUMU
Şimdi güncel FreeBSD ports dizininden yararlanarak rsync kurulumunu gerçekleştirelim;
# cd /usr/ports/net/rsync/ # make
SSH, FLAGS ve ACL seçeneklerini seçerek devam ediyoruz. Kurulum esnasında rsync paketi (rsync-3.0.6.tar.gz) ve patchleri (rsync-patches-3.0.6.tar.gz) yüklenecektir.
# make install clean
Kurulum tamamlandıktan sonra rsync’in sistem açılışlarında otomatik olarak başlayabilmesi için /etc/rc.conf dosyamızın içerisine ilgili satırı ekliyoruz;
# echo 'rsyncd_enable="YES"' >> /etc/rc.conf
Rsync yapılandırma dosyasını aşağıdaki şekilde düzenleyeceğiz. Mevcut rsyncd.conf dosyası içerisinde üst kısımda yer alan GLOBAL PARAMETRELER kısmında rsync’in çalışmasına yönelik genel yapılandırma ayarlarını oluşturuyoruz. log file parametresi ile tüm modüllere ilişkin genel transfer loglarının tutulacağı dizini belirtirken, use chroot = yes parametresi ile chroot (yeni kök dizini belirleme) özelliğini aktive edip, uid ve gid değerleri ile chroot için hangi kullanıcı ve grubun geçerli olacağını, charset = utf-8 parametresi yardımıyla transferi gerçekleşen dosyaların isimlerinde özellikle windows – unix geçişlerinde karakter bozulmaları yaşamamak için UTF-8 karakter setinin kullanılacağını belirtiyoruz. Ardından MUDÜL PARAMETRELERİ bölümünde bu sunucuya yedek dosyaları göndermelerine izin verilecek her bir modülü (makinaları) ayrı ayrı host isimleriyle tanımlayarak, güvenlik amacıyla makina bazında IP adresi erişim kısıtlamalarını, uygulamadaki muhtemel güvenlik açıklarına karşı ekstra koruma sağlayabilmek adına chroot mekanizmasının ilgili modül için devrede olacağını ve /./ (dot-dir) ile modül dizininde chroot’un gerçekleşeceği noktayı belirtiyoruz. Bu transfer hiyerarşisinin tepesi için chroot’un sistemin “/” ana kök dizininden tamamen bağımsız çalışmasını sağlayacaktır. Biz client, yani yedeği gönderecek taraf için konuyu irdeleyebilmek için aşağıdaki örnek yapılandırma dosyası içerisinden, üzerinde yedeği alınması gereken çeşitli dosya ve klasörler ile MSSQL veritabanı yedekleri bulunan bir Microsoft Windows sunucusu olan [mikrodb] ve bir Apache web sunucusu olan [websrv-01] modülleri ile ilgili detayları ele alıyor olacağız. Siz uygulamada istediğiniz sayıda modülü aşağıdaki isimleri ve ilgili IP adreslerini kendi ağınızda bulunan makinaların değerlerine göre düzenleyerek dilediğiniz çapta bir yedekleme uygulaması gerçekleştirebilirsiniz.
# vi /usr/local/etc/rsyncd.conf
# rsyncd.conf - Example file, see rsyncd.conf(5) # GLOBAL PARAMETERS # Set this if you want to stop rsync daemon with rc.d scripts pid file = /var/run/rsyncd.pid log file = /usr/backups/transfer.log lock file = /var/run/rsyncd.lock charset = utf-8 # Edit this file before running rsync daemon!! uid = root gid = backup use chroot = yes max connections = 15 #Max. concurrent connection limit to rsync server syslog facility = local5 # MODULE PARAMETERS [companydc] path = /usr/backups/./companydc use chroot = yes read only=no transfer logging=yes hosts allow=192.168.1.10 hosts deny=* [mikrodb] path = /usr/backups/./mikrodb use chroot = yes read only=no transfer logging=yes hosts allow=212.x.x.145 hosts deny=* [webdb] path = /usr/backups/./webdb use chroot = yes read only=no transfer logging=yes hosts allow=212.x.x.132 hosts deny=* [websrv-01] path = /usr/backups/./websrv-01 use chroot = yes read only=no transfer logging=yes hosts allow=212.x.x.129,212.x.x.145 hosts deny=* [mail] path = /usr/backups/./mail use chroot = yes read only=no transfer logging=yes hosts allow=212.x.x.136 hosts deny=* [ux] path = /usr/backups/./ux use chroot = yes read only=no transfer logging=yes hosts allow=212.x.x.131 hosts deny=* [ns1] path = /usr/backups/./ns1 use chroot = yes read only=no transfer logging=yes hosts allow=88.x.x.28 hosts deny=*
Farklı gereksinimlerinize yönelik olarak bu yapılandırma dosyasında kullanabileceğiniz diğer tüm parametreleri http://www.samba.org/ftp/rsync/rsyncd.conf.html sayfasında inceleyebilirsiniz.
Şimdi rsync uygulamamızı başlatalım;
# rsync --daemon
Kontrol edelim;
# ps aux | grep rsync root 66415 0.0 0.0 3128 1348 ?? Ss 8:49PM 0:00.00 rsync –daemon
Gerektiğinde rsync servisini yeniden başlatabilmek ve ya standart stop/start manüplasyonları için aşağıdaki komutları kullanabilirsiniz;
# /usr/local/etc/rc.d/rsyncd restart # /usr/local/etc/rc.d/rsyncd stop # /usr/local/etc/rc.d/rsyncd start
# netstat -a | grep rsync tcp4 0 0 *.rsync *.* LISTEN tcp6 0 0 *.rsync *.* LISTEN
Görüldüğü gibi sunucumuz rsync portu olan TCP 873 ‘ü dinlemeye başlamış durumda. Yedeğini almak istediğiniz sunucu ve istemcileriniz firewallunuz tarafından korunan ve yedeklerin tutulacağı FreeBSD sunucumuzdan farklı DMZ ve ya ağlarda bulunuyorsa, firewallunuzda bu düğümlerden rsync sunucumuza doğru TCP 873 portuna izin verecek şekilde ayar gerçekleştirmeyi unutmayınız. Ayrıca farklı ağlarda bulunan bu makinaların farklı firewall ethernet interface lerine tanımlı muhtelif NAT kurallarından dolayı yedekleme sunucusu tarafından kendi gerçek ethernet IP leri ile görülemeyebileceğini de göz önünde bulundurarak gerekiyorsa rsyncd.conf içerisindeki modül IP lerini söz konusu NAT IP’lerine göre düzenleyiniz.
CRON AYARLARI
Yedeklerin yönetimi ve raporlaması için betiklerimizi cron ile otomatikleştirmek üzere gerekli ayarlamaları yapmalıyız. Önce root için mevcut cron ayarlarımızı kontrol edelim;
# crontab -l crontab: no crontab for root
Henüz root kullanıcısı için bir cron ayarı bulunmadığını görüyoruz. Oluşturmak için crontab -e komutunu kullanarak bir crontab tmp dosyası hazırlanmasını sağlıyoruz ve “vi” editöründe olduğu gibi ESC, i tuşlarını kullanarak giriş yapmaya başlıyoruz. Aşağıdaki örnekte görüldüğü şekilde önce /usr/backups/ dizininde bulunan transfer.log dosyasının sıkıştırılarak saklanması, yenisinin oluşturulması ve 7 günden eski sıkıştırılmış log dosyalarının silinmesi işlemini gerçekleştiren rotate-transfer-logs.sh scriptinin her gece 00:00′da çalıştırılmasını sağlayacak tanımı oluşturuyoruz. Ardından rsyncd.conf ve variables.inc içerisinde belirttiğimiz her bir host için gerekli tanımlamaları ayrı ayrı giriyoruz.
SHELL=/usr/local/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/etc
satırlarına dikkat edelim. Bunlar cron’un hangi kabukta (bash) çalışacağını ve hangi çevresel değişkenleri kullanacağını ifade eden satırlar olup, eksik ve ya yanlış girildiğinde betiklerinizin komut satırından düzgün çalışmasına rağmen cron içerisinden otomatik yürütülememesine sebep olacaktır. Ayrıca dikkat ederseniz host için yapılan her tanımda script çalıştırılmadan önce o hosta ilişkin dizine gidilmesi sağlanmaktadır. Bunun sebebi ilgili script içerisinde yer alan bir takım değişkenlerin özellikle dizin tesbiti ve kontrolü amacıyla üst dizinlerden referans alıyor olmasıdır.
# crontab -e
SHELL=/usr/local/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/etc #minute hour mday month wday command # Daily rotation for rsync transfer.log 0 0 * * * /usr/backup-sys/server/rotate-transfer-logs.sh # Backup management and reporting for folders and database of host: mikrodb 30 4 * * * cd '/usr/backup-sys/agents/mikrodb' && /usr/backup-sys/agents/mikrodb/mikrodb-control.sh 0 5 * * * cd '/usr/backup-sys/agents/mikrodb' && /usr/backup-sys/agents/mikrodb/mikrodb-control-db.sh # Backup management and reporting for folders and database of host: websrv-01 30 5 * * * cd '/usr/backup-sys/agents/websrv-01' && /usr/backup-sys/agents/mikrodb/websrv-01-control.sh 0 6 * * * cd '/usr/backup-sys/agents/websrv-01' && /usr/backup-sys/agents/mikrodb/websrv-01-control-db.sh
Tanımlamarımızı bitirdikten sonra :wq! ile dosyayı kaydederek çıkalım.
/tmp/crontab.9WEzi5dlRx: 9 lines, 662 characters. crontab: installing new crontab
Böylece root için yeni crontab install etmiş olduk.
HOST (İSTEMCİ) TARAFINDAKİ AYARLAR
Bu başlık altında yedekleri gönderecek olan host yani istemci (client) makinalarda yapılması gerekenleri anlatıyor olacağım. Microsoft ve *NIX olarak ikiye ayırırsak her iki tip OS için yapılması gerekenler aşağıda detaylarıyla verilmektedir.
Microsoft Sunucu ve İstemciler:
Aşağıdaki linkleri kullanarak cwRsync_3.1.0_Installer.zip ve UTF8-cwrsync-dll.rar dosyalarını sunucu ve ya istemcinize indiriniz.
.
.
cwRsync_3.1.0_Installer.zip dosyasını açarak içerisinde bulunan cwRsync_3.1.0_Installer.exe dosyasını çalıştırınız ve kısa yönergeleri takip ederek kurulumunu C:\Program Files altına gerçekleştiriniz. Ardından UTF8-cwrsync-dll.rar dosyasını açınız ve UTF8-cwrsync-dll klasörü içerisinde bulunan cygwin1.dll dosyasını C:\Program Files\cwRsync\bin\ altında bulunan cygwin1.dll dosyasının üzerine kopyalayınız. Logların kaydedilebilmesi için C:\Program Files\cwRsync\bin\ altında rsync.log isminde bir text dosyası yaratınız. Bu loglar yedeği alınacak data ile birlikte rsync sunucusuna gönderilecektir. Bu işlemleri tamamladığınızda Microsoft sunucu ve ya istemciniz Rsync sunucunuz ile haberleşmeye hazır hale gelmiş olacak.
Diyelim ki web sunucunuzda (websrv-01.mydomain.com) bulunan F:\AppFolder isimli uygulama klasörünüz ve içindekilerin yedeklerini almak istiyor olalım. Ve yukarıda kurulumunu gerçekleştirdiğiniz Rsync sunucunuzun IP adresi de 212.x.x.1 olsun. Bu senaryoyu gerçekleştirmek için yedeği alınacak sunucunuzda ms-rsync.bat isimli bir batch dosyası oluşturarak yedekleme işlemini özel rsync komut ve parametreleri ile tanımlayalım;
@ECHO OFF REM ********************************************* REM MS-RSYNC.BAT; Batch file to synch F:\AppFolder and logs to Rsync server. REM ********************************************* @echo Processing MAIN RSYNC Transfer ... del C:\Progra~1\cwRsync\bin\rsync.log C:\Progra~1\cwRsync\bin\rsync -rltpED "--chmod=u=rwx,g=rx,o=" --itemize-changes --delete --stats /cygdrive/f/AppFolder 212.x.x.1::websrv-01 >C:/Progra~1/cwRsync/bin/rsync.log C:\Progra~1\cwRsync\bin\rsync -rltpED "--chmod=u=rwx,g=rx,o=" /cygdrive/c/Progra~1/cwRsync/bin/rsync.log 212.x.x.1::websrv-01 @echo Done ! exit
Dilerseniz şimdi konuya daha iyi hakim olabilmeniz için kullandığımız komutlar ve ilgili parametreleri inceleyelim:
C:\Progra~1\cwRsync\bin\rsync komutunu MSDOS betiği içerisinde ifade ederken “Program Files” ifadesindeki kelimeler arasındaki boşluğu özellikle “Progra~1” şeklinde elemine ettiğimize dikkat etmişsinizdir. Uygulamalarımızda bunu unutmayalım.
-rltpED parametre kümesi içerisindeki;
-r: (–recursive) kopyalarken klasörler içerisinde özyineleme yap
-l: (–links) sembolik linkleri değiştirmeden olduğu gibi kopyala
-t: (–times) verilerin değiştirilme (modification) zamanlarını koru
-p: (–perms) veriler için tanımlı izinleri koru
-E: (–executability) dosyaların çalıştırılabilirliğini koru
-D: (–devices –specials) aygıt dosyalarını ve özel dosyaları koru
“–chmod=u=rwx,g=rx,o=” parametre kümesi içerisindeki;
–chmod: Bu parametre virgülle ayrılmış bir ve ya daha fazla dosya izin dizisinin, transferi gerçekleşen dosyaların izin tanımlamalarına uygulanmasını sağlar. Özetle diyebilirizki Rsync sunucusuna transfer edeceğimiz her bir dosyanın izin bitlerini uygulamamızın amacına göre yeniden belirleyerek değiştiriyoruz.
Bu anlamda;
u=rwx (user bitleri) root kullanıcısı için okuma,yazma ve çalıştırma haklarını atarken
g=rx (grup bitleri) kurulumu yaparken yarattığımız “backup” grubu için sadece okuma ve çalıştırma haklarını atamakta
o= (others bitleri) ise boş bırakıldığı için root ve backup dışında kalan tüm kullanıcı ve gruplara tüm erişim izinlerini iptal etmektedir.
Bu sayede yedeklerimizi Rsync sunucusuna aktardığımızda root ve backup grubu haricinde kimse herhangi bir metod (ftp, NetBIOS, vb.) ile geri yükleme, inceleme ve ya en önemlisi değişiklik gerçekleştiremeyecektir. Bu sebeple rsyncd.conf içerisinde ve /usr/backups depolama alanı dizininde özellikle root:backup sahipliklerini belirtmiş idik. Elbette uygulamamız, yedekleme amacıyla oluşturduğumuz bir backup ünitesi olduğu için bu modeli uygun gördük. Şayet bir NAS uygulaması gerçekleştirmek ve herkesin verilere erişebilmesini isteseydik rwxr-x— (750) yerine rwxrw-rw- (766) bitlerini ve ya benzerini kullanmayı tercih edebilirdik.
–itemize-changes: Öznitelik değişiklikleri de dahil olmak üzere her bir dosya üzerinde gerekleşen değişikliklerin ayrıntılı dökümünü talep eder. Bu paramtre sayesinde raporlama mailinde senkronizasyonun gerçekleştiği günde kaynakta hangi dosyaların ne şekilde modifiye edildiğini, bu nedenle hangi dosyaların senkronizasyona sokularak sunucumuza transfer edildiğini görebiliyoruz. Sonuç olarak kaynakta değişikliğe uğramış dosyaları tek tek takip edebilme imkanına kavuştuğumuz için güvenlik açısından da son derece faydalı bir gözlemleme imkanına sahip olmuş oluyoruz.
–delete: Alıcı tarafında (Rsync sunucusunda) geçerliliği kalmamış, artık kaynakta bulunmayan eski dosyaların yedekleme yapılırken otomatik olarak silinmesini sağlar.
–stats: Dosya transferlerine ilişkin olarak rsync’in delta-transfer algoritmasının verileriniz için ne kadar efektif olduğunu anlamanıza imkan verecek olan detaylı istatistik seti oluşturur.
/cygdrive/f/ cwRsync uygulamasının Microsoft Windows sistemlerdeki disk ve dilimleri ifade etme (unix tarzında) şeklidir. (=> F:\)
AppFolder, örneğimizde yedeği alınacak olan klasör.
212.x.x.1::websrv-01, AppFolder klasörünün ve içerğinin 212.x.x.1 IP adresine sahip Rsync sunucusu üzerinde bulunan ve rsyncd.conf içerisinde tanımlı (path = /usr/backups/./websrv-01) websrv-01 depolama alanına gönderileceğini ifade eder.
>C:/Progra~1/cwRsync/bin/rsync.log ibaresi ile gerçekleşen transfere ilişkin logları yazdırıyor ve bir alt satırda yine websrv-01 depolama alanına teslim ediyoruz.
Artık ms-rsync.bat cmd script dosyasını, karşı tarafta yani Rsync sunucunuzdaki yönetim ve raporlama işlemlerine ilişkin olarak cron içerisinde tanımlı çalışma saatlerini de dikkate alarak, Planlanmış İşlemler (Scheduled Tasks) içerisine kaydedip otomatik olarak çalışmasını sağlayabilirsiniz. Elbette ms-rsync.bat işleminin çalışma zamanını, Rsync sunucusunda bu hosta ilişkin yönetim ve raporlama işlemlerinin devreye girdiği cron saatinden daha öncesine ayarlamak mantıklı olacaktır. Bunu yaparken senkronizasyona sokulacak yedeğinizin büyüklüğünü ve transferi için gerekecek süreyi göz önünde bulundurmayı unutmayınız.
Farklı gereksinimleriniz ve deneysel çalışmalarınıza yönelik olarak rsync komutu ile kullanabileceğiniz diğer tüm parametreleri http://www.samba.org/ftp/rsync/rsync.html adresinde inceleyebilirsiniz.
HATIRLATMA: Yedekleme stratejilerinizi ve yedeği alınacak klasörleri belirlerken, çeşitli uygulama geliştirme teknikleri kullanarak daha süratli servis vermek amacıyla faydalanılan ve genellikle içerisinde binlerce görsel objenin bulunduğu CACHE vb. klasörleri rsync senkronizasyonuna sokmanızın efektif, daha doğrusu gerekli olmayacağını göz önünde bulundurmanızı tavsiye ederim. Bu zaman ve gereksiz kaynak kullanımına neden olacaktır.
Şimdi Microsoft sistemlerde rsync kullanımına ilişkin alt başlığımızı farklı bir örnekle çeşitlendirerek noktalayalım;
@ECHO OFF REM ********************************************* REM MS-RSYNC.BAT; Batch file to synch Mikro accounting folders, MSSQL FULL|DIFF|TRN DB backups and logs to Rsync server. REM ********************************************* C:\Progra~1\cwRsync\bin\rsync -rav --stats --delete /cygdrive/f/Mikro/v12xx/COMPANY-A-09/PARAMS /cygdrive/f/BACKUP/MIKROFolders/COMPANY-A-09/ C:\Progra~1\cwRsync\bin\rsync -rav --stats --delete /cygdrive/f/Mikro/v12xx/COMPANY-A-09/SYSTEM /cygdrive/f/BACKUP/MIKROFolders/COMPANY-A-09/ C:\Progra~1\cwRsync\bin\rsync -rav --stats --delete /cygdrive/f/Mikro/v12xx/COMPANY-B-09/PARAMS /cygdrive/f/BACKUP/MIKROFolders/COMPANY-B-09/ C:\Progra~1\cwRsync\bin\rsync -rav --stats --delete /cygdrive/f/Mikro/v12xx/COMPANY-B-09/SYSTEM /cygdrive/f/BACKUP/MIKROFolders/COMPANY-B-09/ C:\Progra~1\cwRsync\bin\rsync -rav --stats --delete /cygdrive/c/MikroXML /cygdrive/f/BACKUP/MIKROFolders/ del C:\Progra~1\cwRsync\bin\rsync.log del C:\Progra~1\cwRsync\bin\rsyncdb.log @echo Processing MAIN RESYNC Transfer ... C:\Progra~1\cwRsync\bin\rsync -rltpED "--chmod=u=rwx,g=rx,o=" --itemize-changes --delete --stats /cygdrive/f/BACKUP/MIKROFolders 212.x.x.1::mikrodb >C:/Progra~1/cwRsync/bin/rsync.log C:\Progra~1\cwRsync\bin\rsync -rltpED "--chmod=u=rwx,g=rx,o=" --itemize-changes --delete --stats /cygdrive/f/BACKUP/AUTOCURRENT 212.x.x.1::mikrodb >C:/Progra~1/cwRsync/bin/rsyncdb.log C:\Progra~1\cwRsync\bin\rsync -rltpED "--chmod=u=rwx,g=rx,o=" /cygdrive/c/Progra~1/cwRsync/bin/rsync.log 212.x.x.1::mikrodb C:\Progra~1\cwRsync\bin\rsync -rltpED "--chmod=u=rwx,g=rx,o=" /cygdrive/c/Progra~1/cwRsync/bin/rsyncdb.log 212.x.x.1::mikrodb @echo Done ! exit
Yukarıdaki örnekte rsync senkronizasyonundan önce yedeği alınacak olan yerel C:\ ve F:\ dizinlerindeki farklı firma klasörlerini yine önce yerel F:\ dizini üzerindeki \BACKUP\MIKROFolders\ klasörü altında toplayarak birleştiriyoruz. Yerel lokasyonlar arasında kopyalama gerçekleştirdiğimiz için sadece -rav (-a: –archive, arşivleme modu) parametrelerini kullanıyoruz. Ardından bir önceki rsync senkronizasyonuna ilişkin logları temizliyoruz. Son olarak MIKROFolders klasörü ile birlikte MS SQL üzerinde “Maintenance Plan” ile oluşturduğumuz yedekleme stratejisi sayesinde içerisinde gün boyunca aldığımız full, differential ve transaction log yedeklerini bulunduran \BACKUP\AUTOCURRENT klasörünü ve tüm logları Rsync sunucusuna transfer ediyoruz.
Özellikle sık aralıklarla alınacak olan DIFF ve TRN yedeklerini Rsync sunucusuna aktarabilmek için ms-rsync.bat cmd betiğini Planlanmış İşlemler (Scheduled Tasks) içerisinde geceyarısı, sabah, öğlen ve akşam olmak üzere günde bir kereden fazla çalışmak üzere programlamanız gerekecektir.
*NIX sunucular:
Yedekleri gönderecek olan unix ve linux sistemlerde tıpkı Rsync sunucusunda olduğu gibi rsync kurulumunu (rsync-3.0.6.tar.gz) gerçekleştirmeliyiz. Ancak sunucuda olduğu gibi –daemon olarak çalıştırmamız ve /etc/rc.conf içerisine ekleyerek sunucu yeniden başlatıldığında çalışmasını sağlamamız gerekmeyecektir. Gönderici taraf olacak sistemde sadece “rsync” komutundan faydalanarak yedeklerimizi transfer edeceğiz. İşte örnekler;
#!/usr/local/bin/bash # rsync.sh; synchronizes hosted web folders under /usr/local/www/apache22/data path to Rsync server. # # WEB FOLDERS rsync -rav --itemize-changes --stats --delete /usr/local/www/apache22/data/WEBSITE.COM 212.x.x.1::hostingsrv > /space/rsync-website.com.log rsync -rav --itemize-changes --stats --delete /usr/local/www/apache22/data/WEBSITE.NET 212.x.x.1::hostingsrv > /space/rsync-website.net.log # LOGS rsync -rav /space/rsync-website.com.log 212.x.x.1::hostingsrv rsync -rav /space/rsync-website.net.log 212.x.x.1::hostingsrv exit
Görüldüğü üzere aynı tür OS sistemler arasındaki transferlerde -rav parametrelerini kullanmamız kafidir. /space dizini altında ilgili rsync-*.log dosyalarını oluşturmayı unutmamamız gerekmekte.
Şimdi yukarıdaki örneğimizde ele aldığımız hosting sunucusu üzerinde, MySQL Veritabanlarının Yedeklenmesi başlıklı makalemizde anlatıldığı şekilde oluşturulmuş çoklu MySQL yedeklerinden bugüne ait olanlarını aşağıdaki betikle Rsync sunucumuza transfer edelim.
#!/usr/local/bin/bash # rsyncdb.sh; transfers all MySQL DB backups to Rsync server. # # MYSQL DATABASES rsync -ravx --stats /space/backup/*-backup-`date +%Y.%m.%d`*.sql.gz 212.x.x.1::hostingsrv exit
Söz konusu transferleri düzenli bir hale getirmek üzere cron tanımı gerçekleştirelim;
# crontab -e
SHELL=/usr/local/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/etc #minute hour mday month wday command # Synch Web folders daily (/w logs) to Rsync server 50 0 * * * /space/rsync.sh # Transfer daily MySQL database backups to Rsync server 20 1 * * * /space/rsyncdb.sh
PART-2′de control scriptlerinin içeriğini ve özelleştirme için bu scriptler içerisinde neler yapabileceğinizi ele almak üzere şimdilik makalemizin bu ilk kısmını noktalıyoruz.
İlgili Makaleler
İlgili makale bulunamadı.
RSS feed for comments on this post.
