lf321, SystemAdministration: storeBackup, alışılmamış yedekleme aracı

<-- | Ana Sayfa | Erişimdüzeni | İçindekiler | Arama

Duyumlar

Belgelikler

Bağlantılar

LF Nedir

Bu makalenin farklı dillerde bulunduğu adresler: English ChineseGB Deutsch Francais Italiano Turkce

Heinz-Josef Claes
<hjclaes(at)web.de>

Yazar hakkında:

Yazar kendi resmini İnternette yayınlamak istemiyor.

Türkçe'ye çeviri:
Erdal Mutlu <erdal(at)linuxfocus.org>

İçerik:

Neden yeni bir yedekleme aracı ?
Kusursuz bir yedekleme aracı nasıl olmalıdır?
StoreBackup nasıl çalışmaktadır?
Özellikleri
Başarım
Gerçekleştirme
Yükleme
Kullanım
Gelecekle ilgili planlar
Sürümler ve lisans
Bu yazı için görüş bildiriminde bulunabilirsiniz

storeBackup, alışılmamış yedekleme aracı

Özet:

StoreBackup, bantlara yedekleme yapan bir sisteme sahip olmayan, ancak ikinci bir diski veya bilgisayarı olan kullanıcılar için tasarlanmıştır. StoreBackup iş ortamlarında çok hızlı ve rahat bir şekilde yedeklerine ulaşmak isteyen kullanıcıların kullanımına yönelik yazılmıştır. Bununla birlikte, sistem yönetimi masrafları da önemli ölçüde azaltılmaktadır.

Diskler ve benzeri aygıtlar, bantlara yapılan yedekleme yerine veya onun yanında kullanabilirler. Burada tanıtılan program yüksek başarım ve yer tasarufu sağlamaktdır:

Dizinler içindekilerle birlikte başka bir yere kopyalanabilmetkedir (Sözgelimi, /home => /var/bkup/2003.12.13_02.04.26) Kapyalanan dosyaların erişim hakları aynı kalmaktadır. Böylece, kullanıcılar, yedeklerine doğrudan ulaşabilmektedir.
Kopyalanmakta olan dosyalar, yedekteki dosyalarla karşılaştırılmakta, böylece yedekler arasında içeriği aynı olan dosyadan sadece bir tane bulunması sağlanmaktadır.
Yedeklerde bulunan aynı dosyalardan bir tane vardır, diğerleri de buna sabit bağlantıyla bağlanmıştır. Dolayısıyla, dosyalar asıl yerlerinde olduğu gibi gözükmektedir.
Eğer, özel olarak 'exclude' (esgeç) ile işaretlenmemişlerse, yedeklenen dosyalar sıkıştırılacaktır. Sıkıştırma işlemi tamamen de iptal edilebilir.
Birbirinden bağımsız olarak yaratılan yedekler (Sözgelimi farklı bilgisayarlardan yaratılmış olanlar.), sabit bağlantılarla paylaşılmakta olan dosyaları gösterebilirler. Kısmi veya tam yedekleme, aynı içeriğe sahip bir dosyanın yedeklerde sadece bir yerde bulunacağı koşulu altına bu yöntemle yapılabilir.

_________________ _________________ _________________

Neden yeni bir yedekleme aracı ?

Şimdilerde, belki binlerce yedekleme programı vardır. Öyleyse, bir başkasına neden gereksinim duyulsun? Gereksinim, benim danışman olarak çalışmamdan ortaya çıktı. Tüm hafta boyunca çeşitli yerlerde çalışıyordum ve dosyalarımı evde yedekleyecek bir aracım yoktu. Tek sahip olduğum, paralel bağlantı noktasına takılı 250 MB kapasitesine sahip bir ZIP sürücüydü. ZIP sürücünün kapasitesi küçük geliyordu ve onun sağlamış olduğu düşük başarımına (saniyede 200KB) katlanmak zorundaydım. Bunun yanı sıra, yedeklerime hızlı olarak erişmem gerekiyordu. Tam ve farkların yedeklendiği bilinen yedekleme yöntemini de (tar veya dump ile yapılanları) beğenmiyordum. Bu yöntemde, bir yandan istediğiniz dosyaya ulaşmak oldukça karmaşık, diğer yandan ise, önceden planlanmadan eski yedek dosyanızı kafanıza göre hemen silemiyorsunuz.

Amacım, işte yedeklemeyi hızlıca yapabilmek, istediğim dosyayı da çabucak bulabilmektir.

Böylece, 1999'da storeBackup'ın ilk sürümü ortaya çıktı. Ancak, bu haliyle büyük ortamlarda kullanılmaya uygun değildi. Programın başarımı iyi değildi, ölçeklendirme sorunları vardı ve isimlerinde garip karakterler ('\n' gibi) içeren dosylarda sorun çıkartmaktaydı.

İlk sürümden elde ettiğim tecrübeler ışığında, yaklaşık bir yıl kadar önce ikinci sürümü yazdım ve GPL lisansı ile yayımladım. Bu arada kullanıcı sayısı da arttı. İnternet servis sağlayıcılarındaki (elektronik posta) dizinlerini yedekleyen ev kullanıcılarından, hastanelerde ve üniversitelerdeki kullanıcılara kadar, kullanıcı çeşitliliğin oluşmasının yanısıra, program genel arşivleme aracı olarak da kullanılmaya başlandı.

Kusursuz bir yedekleme aracı nasıl olmalıdır?

Kusursuz bir yedekleme aracı, tüm verilerin yedeğini erişim haklarını koruyarak günlük olarak başka bir sisteme alan, bunu yaparken sistem yöneticisine mümkün olduğu kadar az yük getiren ve kullanıcıların rahatlığını en üst seviyede tutan bir araç olmalıdır. Bu arada, bunu sağlayacak sistemler ve bilgisayarlar en fazla güvenliği sağlamak amacıyla farklı yerlerde ve binalarda olmalıdır. Bir veri tarayıcısı aracılığı ile kullanıcılar yedeklenmiş dosyaları görüntüleyebilmeli ve gerektiğinde kopyalayabilmelidir. Yedekler doğrudan ve sorunsuz olarak kullanılabilmelidir. Yedeklerle çalışmak 'sıradan' iş haline gelmelidir, çünkü genellikle bu iş için sistem yönetimine gereksinim kalmayacaktır.

Burada tanımlanan sürecin bazı eksileri vardır: Çok fazla disk kapasitesine gereksinim duymakta ve her defasında tüm verilerin kopyalanması gerektiğinden, yavaş çalışmaktadır.

StoreBackup nasıl çalışmaktadır?

StoreBackup "kusursuz yedekleme" gibi davranmaya ve şü iki sorunu gidermeye yönelik çalışmaktadır: yer ve başarım.

Özellikleri

Eğer, sizin için bir şey ifade ediyorsa, yer kullanımını azaltmak için yapılabilecek ilk iş, dosyaları sıkıştırmak olacaktır. storeBackup sıkıştırmak için herhangi bir programın kullanımına olanak sağlamaktadır. Benimsenmiş değer olarak bzip2 kullanılmaktadır.

Yedeklenen verileri daha yakından izlediğiniz zaman, yedekten yedeğe çok az sayıda dosyanın değiştiğini göreceksiniz. Bu yüzden fark (incremental) yedekleme yöntemleri doğmuştur. Farkettiğimiz olaylardan birisi de, aynı içeriklere sahip bir çok dosya yedekte bulunabilmektedir. Bunun nedeni, ya kullanıcılar tarafından kopyalanmış olmaları, yada cvs gibi sürüm yönetim programların işbaşında olmasıdır. Bunlara ek olarak, kullanıcılar dosya veya dizin isimlerini yedeklerde değiştirmektedirler. Böylece, fark yedekleme yöntemlerinde bu dosyalar gereksiz yere tekrar yedeklenmektedir. Soruna çözüm olarak yedeklere bakıp, eğer aynı içerikte dosya (belkide sıkıştırılmış durumda) varsa, ona sabit bağlantı kurmaktır. (Açıklama: Unix sistemlerindeki veri parçaları inode'lar tarafından yönetilmektedir. Birçok farklı dizindeki dosya bir inode'u gösteriyor olabilir. Gerçek dosya, inode'a olan sonuncu bağlantı (=dizin adı) silindiğinde silinmektedir. Sabit bağlantılar aynı dosya sistemi içinde yapılabilmektedir.)

Diskte sadece bir defa yer almasına karşın, sabit bağlantı tekniği ile, her yedekte gözükmektedir. Dolayısıyla bu tür dosya ve dizinlerin kopyalanması veya isimlerinin değiştirilmesi sadece sabit bağlantı için gerekli yer kadar, ki bu çok azdır, disk alanı gerektirmektedir.

Büyük bir olasılıkla yedeklenmesi gereken birden fazla bilgisayar vardır. /etc veya /usr gibi dizinlerde aynı içeriğe sahip dosya sayısı oranı oldukça yüksektir. Açıktır ki, aynı dosyadan sadece bir tane yedeklerde yer almalıdır. En kolayı, tüm bilgisayarların dizinlerini, yedeklemeyi yapacak sunucu tarafından bir dizine (mount) bağlanarak, bir çırpıda yedeklemeyi yapmaktır. Böylece, aynı içerikli dosyaların farkına varılıp, sabit bağlantılar yapılabilir. Ancak, bu çözümün eksiği, yedekleme zamanı geldiğinde tüm bilgisayarların çalışır durumda olması gerekmesindedir. Bu yöntem, dizüstü bilgisayarların da storeBackup tarafından yedeklenmesi gerektiği durumda olduğu gibi birçok durumda uygun olmayabilir.
Dizüstü bilgisayar kullanıcıları dosyaların kopyalarını aldıklarından, aynı içerikli dosyaların sayısı çok olacaktır. Bu gibi durumlarda veya sunucuların birbirindan ayrı yedeklendiği durumlarda ve disk alanının daha optimal kullanılması gerektiğinde, storeBackup birbilerinden bağımsız yedeklerde de sabit bağlantılar yapabilir.

Dosya silmek için storeBackup birçok seçenek sunmaktadır. Eğer, yedek tam (full) yedek ise, dosyaları gözünüz kapalı silebilirsiniz. Geleneksel yedekleme yöntemlerinde olduğu gibi, fark yedeğinin bu tam yedeğe bağımlı olup olmadığını düşünmeniz gerekmiyor.
Seçenkler, yedeklerin haftanın, ayın veya seninin ilk veya son günü yada haftanın belli günlerinden saklanması veya silinmesine olanak sağlamaktadır. Belli sayıdaki yedeğin hep kalması sağlanabilir. Sözgelimi, dizüstü bilgisayarlarda yedekleri üç hafta süreyle saklanması gerektiğini belirttiğiniz halde, dört haftalık tatil süresi boyunca yedekleri saklamanız olasıdır. Dahası, yapılabilecek en fazla yedek sayısı tanımlamak da olasıdır.

Başarım

Yukarıda açıklanan yöntem, yeni bir yedek alınmadan önce, aynı içerikteki dosyanın eski yedeklerde olup olmadığına bakıldığını varsaymaktadır. Yedeklenecek her dosyayı önceki yedektekiyle doğrudan karşılaştırmak çok fazla bir şey ifade etmemektedir. Bunun yerine md5 toplamları karşılaştırılmakta ve hash tabloları kullanılmaktadır. Ayrıca, program bu bilgileri saklamak için dbm dosyaları kullanmaktadır.
md5 toplamlarını hesaplamak hızlı bir işlemdir. Ancak, çok fazla sayıda veri olduğunda yeterince hızlı sayılmaz. Bu nedenle storeBackup, ilk önce son yedeklemeden beri dosyada bir değişikliğin olup olmadığına (yoltanımı + dosya ismi, ctime, mtime ve boyut) bakmaktadır. Eğer, değişiklik yoksa md5 toplamı, eski yedekten alınmakta ve dosya kopyalanmaya gerek kalmadan sadece sabit bağlantı oluşturulmaktadır. Eğer, değişiklik görülürse, dosyanın md5 toplamı hesaplanmakta ve aynı md5 toplanına sahip başka dosyanın varlığına bakılmaktadır. (Yedekleme serileri olduğu durumlarda bu yöntemin genişletilmiş hali kullanılmaktadır.) Böylece, çok az sayıda md5 toplamının hesaplanması gerekmektedir.

200 MHz, IDE olan sunucum saniyede 20 ila 35 dosya, 800MHz,IDE olan masaüstü bilgisayarım ise, saniyede 150 ila 200 dosya işleyebilmektedir. 2.4 GHz, 1.4TB yazılımsal RAID olan hızlı bilgisayarlarda saniyede 800 dosyanın işlendiğini gördüm. Bu sonuçlar, bilgisayara doğrudan takılı diskler içindir. NFS kullanıldığında okuma hızları düşmektedir. En önemli etken diskin hızıdır. (Tüm testler Linux bilgisayarlarında yapılmıştır.)

Gerçekleştirme

storeBackup araçları, Linux, FreeBSD, Solaris ve AIX işletim sistemlerinde denenmiştir. Teorik olarak tüm Unix ortamlarında çalışmaları gerekir. Programlama dili olarak Perl kullanılmıştır.

Yükleme

Yükleme işlemi çok basittir. StoreBackup'ı http://www.sf.net/projects/storebackup adresinden elde edebilirsiniz. storeBackup-version.tar.bz2 istediğniz bir dizinde aşağıdaki gibi açabilirsiniz:

tar jxf storeBackup-version.tar.bz2

Bu bulunduğunuz dizinde storeBackup adlı bir dizin ve içinde kullanım belgeleri ile bin dizini altında çalıştırılabilir dosyalar oluşturmaktadır. Programları tam yoltanımı belirterek veya $PATH deyişkenini ayarlayarak da çalıştırabilirsiniz. FreeBSD işletim sisteminde olduğu gibi, md5sum programını kendiliğinden içermeyen ortamlarda derlemeniz gerekebilir. Bununla ilgili açıklamalar programlar ile birlikte gelen README dosyasında yeralamaktadır.

Kullanım

Pakette de yer aldığı için, programın tüm seçeneklerini burada açıklamayacağım.

Yedek almanın en basit yolu asağıdaki gibidir:

storeBackup.pl -s sourceDir -t targetDir

sourceDir ve targetDir dizinleri daha önceden varolmak zorundadır. StoreBackup, sourceDir dizindeki dosyaları targetDir/date_time'a bzip2 ile sıkıştırarak (.gz, bz2, .png gibi olan dosyaları esgeçerek) tekrarları da önleyerek kopyalayacaktır.

storeBackup.pl'in 1.14.1 sürümünde 45 adet parametresi vardır. Bunları burada açıklamak yazının amacı dışına çıkmak anlamına gelecektir. Parametreleri öğrenmek isterseniz, aşağıdaki komutu kullanabilirsiniz:

storeBackup.pl -h

README ve EXAMPLES dosyalarında çeşitli uygulama alanları hakkında ayrıntılı bilgi elde edinebilirsiniz. Programa verilen parametrelerin sayısı arttıkça, hepsini komut satırından girmek hızla karmaşık bir hal alacağından, bunun yerine bir yapılandırma dosyasının kullanılabileceğini belirtmekte yarar var. Yapılandırma dosyasını oluşturmak için aşağıdaki komutu kullanabilirsiniz:

storeBackup.pl --generate --file ConfigFile

veya

storeBackup.pl -g -f ConfigFile

Yapılandırma dosyasında yapmış olduğunuz ayarlamalar sona erdiğinde, dosyada yazım hataları olup olmadığını görmek için

storeBackup.pl -f ConfigFile --print

komutunu kullanabilirsiniz. storeBackup çalıştırmak için ise,

storeBackup.pl -f ConfigFile

komutu kullanılır. storeBackup ile ilgili hertürlü açıklama paketle birlikte gelen README ve EXAMPLES dosyalarında yeralmaktadır.

Bir dosyanın nerede ve hangi sürüm numarasına sahip olduğunu öğrenmek için açaşğıdaki komut kullanılır:

storeBackupVersion.pl -f filename

filename bilgi alınacak dosyanın adıdır. Dosya adını yedekte olduğu gibi, sıkıştırma kullanıldıysa eki ile birlikte yazılmalıdır. Yedeklerin olduğu doğru dizine gitmek ve komut çalıştırmak en kolay iştir. Programın "-h" parametresini kullanırsanız, 11 adet parametre ile ilgili açıklamalar bulacaksınız.

Tek bir dosyayı yedekten almak için cp, ftp, dosya yöneticisi veya benzeri yöntemler kullanabilirsiniz. Kısmi dizin ağacı veya tüm yedeği geri almak için ise, storeBackup.pl'i kullanmak daha faydalı olacaktır. Böylece, yedekten alınan dosyanın kullanıcı ve erişim hakları da ayarlanmış olacaktır. Eğer, asılları sıkıştırılmamış durumda ise, yedekten alınırken dosyalar açılarak alınmış olacaktır. Asıl sabit bağlantılar da ayarlanacaktır.
storeBackup'da istatistikler ile ilgili seçeneklerde vardır. Okuma istatistiği, başarımı etkileyen parametreler, üzerine yazma seçeneği ve diğerleri olmak üzere toplam 10 adet parametre vardır. Bunların neler olduğunu "-h" seçeneğini kullanarak öğrnebilirsiniz.

storeBackupDel.pl kullanarak yedekleri, storeBackup.pl'den bağımsız olarak silebilirsiniz. Bu özellikle NFS üzerindeki dizinleri silerken kullanışlı olabilir. NFS üzerinden olan kullanımlarda, storeBackup silme seçeneği olmadan çalıştırılabilir. Böylece, yedekleme süresi üzerinde daha çok denetiminiz sağlanmış olur. Silme işlemi yedekleme işleminden ayrılarak, yedekleme yapan sunucu üzerinde storeBackupDel kullanılarak yapılabilir.

Var olan yedekler dizinler halinde durmaktadır. Onları görüntülemek için ls yerine storeBackupls.pl kullanırsanız, yedekler hakkında daha çok bilgi elde edebilirsiniz:

hjc@schlappix:~/backup ) storeBackupls.pl /media/zip/stbu/
  1  Fri May 23 2003   2003.05.23_12.37.53   -156
  2  Fri Jun 06 2003   2003.06.06_14.31.47   -142
  3  Fri Jun 13 2003   2003.06.13_14.17.18   -135
  4  Fri Jun 20 2003   2003.06.20_14.02.35   -128
  5  Fri Jun 27 2003   2003.06.27_14.23.55   -121
  6  Mon Jun 30 2003   2003.06.30_17.34.37   -118
  7  Fri Jul 04 2003   2003.07.04_13.10.06   -114
  8  Fri Jul 11 2003   2003.07.11_13.13.14   -107
  9  Fri Jul 18 2003   2003.07.18_14.03.49   -100
 10  Fri Jul 25 2003   2003.07.25_14.19.19   -93
 11  Thu Jul 31 2003   2003.07.31_17.07.55   -87
 12  Fri Aug 01 2003   2003.08.01_12.16.58   -86
 13  Fri Aug 15 2003   2003.08.15_15.10.19   -72
 14  Sat Aug 23 2003   2003.08.23_06.25.35   -64
 15  Wed Aug 27 2003   2003.08.27_18.21.09   -60
 16  Thu Aug 28 2003   2003.08.28_14.16.39   -59
 17  Fri Aug 29 2003   2003.08.29_14.35.10   -58
 18  Mon Sep 01 2003   2003.09.01_17.19.56   -55
 19  Tue Sep 02 2003   2003.09.02_18.18.46   -54
 20  Wed Sep 03 2003   2003.09.03_16.22.41   -53
 21  Thu Sep 04 2003   2003.09.04_16.59.19   -52
 22  Fri Sep 05 2003   2003.09.05_14.35.20   -51
 23  Mon Sep 08 2003   2003.09.08_20.08.52   -48
 24  Tue Sep 09 2003   2003.09.09_18.45.48   -47
 25  Wed Sep 10 2003   2003.09.10_18.30.48   -46
 26  Thu Sep 11 2003   2003.09.11_17.26.46   -45
 27  Fri Sep 12 2003   2003.09.12_15.23.03   -44
 28  Mon Sep 15 2003   2003.09.15_18.05.19   -41
 29  Tue Sep 16 2003   2003.09.16_18.04.16   -40
 30  Wed Sep 17 2003   2003.09.17_19.03.02   -39
 31  Thu Sep 18 2003   2003.09.18_18.21.09   -38
 32  Fri Sep 19 2003   2003.09.19_14.48.05   -37  not finished
 33  Mon Sep 22 2003   2003.09.22_18.58.55   -34
 34  Tue Sep 23 2003   2003.09.23_18.48.40   -33
 35  Wed Sep 24 2003   2003.09.24_19.32.24   -32
 36  Thu Sep 25 2003   2003.09.25_18.05.38   -31
 37  Fri Sep 26 2003   2003.09.26_14.59.59   -30
 38  Mon Sep 29 2003   2003.09.29_18.42.59   -27
 39  Tue Sep 30 2003   2003.09.30_18.02.03   -26
 40  Wed Oct 01 2003   2003.10.01_17.09.43   -25
 41  Thu Oct 02 2003   2003.10.02_15.26.33   -24
 42  Mon Oct 06 2003   2003.10.06_20.08.45   -20
 43  Tue Oct 07 2003   2003.10.07_19.46.54   -19
 44  Wed Oct 08 2003   2003.10.08_16.03.23   -18
 45  Thu Oct 09 2003   2003.10.09_16.58.28   -17
 46  Fri Oct 10 2003   2003.10.10_14.21.06   -16
 47  Mon Oct 13 2003   2003.10.13_18.58.24   -13
 48  Tue Oct 14 2003   2003.10.14_16.02.44   -12
 49  Wed Oct 15 2003   2003.10.15_19.04.12   -11
 50  Thu Oct 16 2003   2003.10.16_15.47.51   -10
 51  Mon Oct 20 2003   2003.10.20_09.34.52   -6
 52  Mon Oct 20 2003   2003.10.20_12.16.40   -6
 53  Tue Oct 21 2003   2003.10.21_09.43.40   -5
 54  Tue Oct 21 2003   2003.10.21_11.22.36   -5
 55  Tue Oct 21 2003   2003.10.21_16.01.15   -5
 56  Tue Oct 21 2003   2003.10.21_18.08.07   -5
 57  Wed Oct 22 2003   2003.10.22_10.02.51   -4
 58  Wed Oct 22 2003   2003.10.22_16.09.42   -4
 59  Wed Oct 22 2003   2003.10.22_18.03.05   -4
 60  Thu Oct 23 2003   2003.10.23_08.18.15   -3
 61  Thu Oct 23 2003   2003.10.23_14.16.24   -3
 62  Thu Oct 23 2003   2003.10.23_17.00.36   -3
 63  Fri Oct 24 2003   2003.10.24_13.29.30   -2
 64  Sun Oct 26 2003   2003.10.26_09.08.55   0

'not finished'in anlamı yarıda kesilmiş demektir.)
Yapılandırma dosyasındaki silme koşulları hakkındaki bilgiyi de aşağıdaki komutla görüntüleyebilirsiniz:

hjc@schlappix:~/backup ) storeBackupls.pl -f stbu.conf /media/zip/stbu/
analyse of old Backups in </media/zip/stbu/>:
 Fri 2003.05.23_12.37.53 (156): keepLastOfMonth(400d)
 Fri 2003.06.06_14.31.47 (142): keepLastOfWeek(150d)
 Fri 2003.06.13_14.17.18 (135): keepLastOfWeek(150d)
 Fri 2003.06.20_14.02.35 (128): keepLastOfWeek(150d)
 Fri 2003.06.27_14.23.55 (121): keepLastOfWeek(150d)
 Mon 2003.06.30_17.34.37 (118): keepLastOfMonth(400d)
 Fri 2003.07.04_13.10.06 (114): keepLastOfWeek(150d), keepMinNumber50
 Fri 2003.07.11_13.13.14 (107): keepLastOfWeek(150d), keepMinNumber49
 Fri 2003.07.18_14.03.49 (100): keepLastOfWeek(150d), keepMinNumber48
 Fri 2003.07.25_14.19.19 (93): keepLastOfWeek(150d), keepMinNumber47
 Thu 2003.07.31_17.07.55 (87): keepLastOfMonth(400d), keepMinNumber46
 Fri 2003.08.01_12.16.58 (86): keepLastOfWeek(150d), keepMinNumber45
 Fri 2003.08.15_15.10.19 (72): keepLastOfWeek(150d), keepMinNumber44
 Sat 2003.08.23_06.25.35 (64): keepLastOfWeek(150d), keepMinNumber43
 Wed 2003.08.27_18.21.09 (60): keepMinNumber42, keepWeekDays(60d)
 Thu 2003.08.28_14.16.39 (59): keepMinNumber41, keepWeekDays(60d)
 Fri 2003.08.29_14.35.10 (58): keepLastOfMonth(400d), keepLastOfWeek(150d),
                               keepMinNumber40, keepWeekDays(60d)
 Mon 2003.09.01_17.19.56 (55): keepMinNumber39, keepWeekDays(60d)
 Tue 2003.09.02_18.18.46 (54): keepMinNumber38, keepWeekDays(60d)
 Wed 2003.09.03_16.22.41 (53): keepMinNumber37, keepWeekDays(60d)
 Thu 2003.09.04_16.59.19 (52): keepMinNumber36, keepWeekDays(60d)
 Fri 2003.09.05_14.35.20 (51): keepLastOfWeek(150d), keepMinNumber35, keepWeekDays(60d)
 Mon 2003.09.08_20.08.52 (48): keepMinNumber34, keepWeekDays(60d)
 Tue 2003.09.09_18.45.48 (47): keepMinNumber33, keepWeekDays(60d)
 Wed 2003.09.10_18.30.48 (46): keepMinNumber32, keepWeekDays(60d)
 Thu 2003.09.11_17.26.46 (45): keepMinNumber31, keepWeekDays(60d)
 Fri 2003.09.12_15.23.03 (44): keepLastOfWeek(150d), keepMinNumber30, keepWeekDays(60d)
 Mon 2003.09.15_18.05.19 (41): keepMinNumber29, keepWeekDays(60d)
 Tue 2003.09.16_18.04.16 (40): keepMinNumber28, keepWeekDays(60d)
 Wed 2003.09.17_19.03.02 (39): keepMinNumber27, keepWeekDays(60d)
 Thu 2003.09.18_18.21.09 (38): keepMinNumber26, keepWeekDays(60d)
 Fri 2003.09.19_14.48.05 (37): keepLastOfWeek(150d), keepMinNumber25, keepWeekDays(60d)
 Mon 2003.09.22_18.58.55 (34): keepMinNumber24, keepWeekDays(60d)
 Tue 2003.09.23_18.48.40 (33): keepMinNumber23, keepWeekDays(60d)
 Wed 2003.09.24_19.32.24 (32): keepMinNumber22, keepWeekDays(60d)
 Thu 2003.09.25_18.05.38 (31): keepMinNumber21, keepWeekDays(60d)
 Fri 2003.09.26_14.59.59 (30): keepLastOfWeek(150d), keepMinNumber20, keepWeekDays(60d)
 Mon 2003.09.29_18.42.59 (27): keepMinNumber19, keepWeekDays(60d)
 Tue 2003.09.30_18.02.03 (26): keepLastOfMonth(400d), keepMinNumber18, keepWeekDays(60d)
 Wed 2003.10.01_17.09.43 (25): keepMinNumber17, keepWeekDays(60d)
 Thu 2003.10.02_15.26.33 (24): keepLastOfWeek(150d), keepMinNumber16, keepWeekDays(60d)
 Mon 2003.10.06_20.08.45 (20): keepMinNumber15, keepWeekDays(60d)
 Tue 2003.10.07_19.46.54 (19): keepMinNumber14, keepWeekDays(60d)
 Wed 2003.10.08_16.03.23 (18): keepMinNumber13, keepWeekDays(60d)
 Thu 2003.10.09_16.58.28 (17): keepMinNumber12, keepWeekDays(60d)
 Fri 2003.10.10_14.21.06 (16): keepLastOfWeek(150d), keepMinNumber11, keepWeekDays(60d)
 Mon 2003.10.13_18.58.24 (13): keepMinNumber10, keepWeekDays(60d)
 Tue 2003.10.14_16.02.44 (12): keepMinNumber9, keepWeekDays(60d)
 Wed 2003.10.15_19.04.12 (11): keepMinNumber8, keepWeekDays(60d)
 Thu 2003.10.16_15.47.51 (10): keepLastOfWeek(150d), keepMinNumber7, keepWeekDays(60d)
 Mon 2003.10.20_09.34.52 (6): keepDuplicate(7d)
 Mon 2003.10.20_12.16.40 (6): keepMinNumber6, keepWeekDays(60d)
 Tue 2003.10.21_09.43.40 (5): keepDuplicate(7d)
 Tue 2003.10.21_11.22.36 (5): keepDuplicate(7d)
 Tue 2003.10.21_16.01.15 (5): keepDuplicate(7d)
 Tue 2003.10.21_18.08.07 (5): keepMinNumber5, keepWeekDays(60d)
 Wed 2003.10.22_10.02.51 (4): keepDuplicate(7d)
 Wed 2003.10.22_16.09.42 (4): keepDuplicate(7d)
 Wed 2003.10.22_18.03.05 (4): keepMinNumber4, keepWeekDays(60d)
 Thu 2003.10.23_08.18.15 (3): keepDuplicate(7d)
 Thu 2003.10.23_14.16.24 (3): keepDuplicate(7d)
 Thu 2003.10.23_17.00.36 (3): keepMinNumber3, keepWeekDays(60d)
 Fri 2003.10.24_13.29.30 (2): keepLastOfWeek(150d), keepMinNumber2, keepWeekDays(60d)
 Sun 2003.10.26_09.08.55 (0): keepLastOfMonth(400d), keepLastOfWeek(150d),
                              keepMinNumber1, keepWeekDays(60d)

Şimdiye kadar sözünü ettiğimiz yedekleme programın dışında llt ve multtail programları da vardır. llt programı, dosyaların dosya erişim haklarından yaratma, değiştirme ve erişim zamanlarının görüntülenmesini sağlamaktadır. multitail ise, dosya sayısı bilgisini, "tail-f" komutuna benzer şekilde görüntülemektedir. Ancak, multitail programı tail'e göre daha fazla seçeneğe sahiptir ve daha gelişmiştir.

Gelecekle ilgili planlar

storeBackup'ın gelecekteki sürümü için aşağıdaki özelliklerin eklenmesi öngörülmüştür:

İlk yedek alımı sırasında yapılan sıkıştırmalar için harcanan zamanı bir yana bırakırsanız, en fazla zaman kaybı sabit bağlantılar oluşturulurken ortaya çıkmaktadır. Sabit bağlantı oluşturmak aslında uzun süren bir işlem değildir, ancak sabit bağlantı oluşturulması gerek dosya sayısı çok fazla olduğundan, diğer işlemler karşısında, ki bunlar sıkıştırma gibi paralel yapılabilmekte, önem kazanmaktadır.
storeBackup'ın bir sonraki sürümü, değişim görmüş dosyalar ile dizin yapısını ilk önce yedekleyebilme seçeneği sunacaktır. Böylece, yedekleme sürecinde dosya kopyalama işlemi tamamlanmış olacaktır. İkinci adımda ise, eksik olan sabit bağlantılar oluşturulacaktır. Bu iki işlemi birbirinden tamamen ayrımak sözkonusu olacağından, bunlar ayrı ayrı bilgisayarlarda çalıştırılabilir. Böylece, yeni sabit bağlantılar oluşturmadan önce, birden fazla yedek almak mümkün olacaktır.
Yaptığımız ölçümlere göre, yerel disklere yazma durumunda, bu yöntem öncekine göre 5 ila 10 kat daha yüksek başarım sağlayacaktır. NFS üzerinden yapılan yedekler doğal olarak daha yavaş olacaktır.
Gelecek sürümde arama seçenekleri, buna yeniden yedekleme de dahil, genişletilecektir. Yedekleri, kullanıcıların tanımlamış olduğu dosya adı (deseni), dosya büyüklüğü, ilk yaratılma veya değiştirme zamanı, kullanıcı numarası, grup numarası, dosya erişim hakları ve basit grep'ten oluşan kurallar tanımlanmasına olanak verecek. Kurallar, 've', 'veya' ve seçime bağlı olarak parantezler içerebilecektir.
Gelecek sürümde seçenekler genişletilerek (tar'daki gibi) aygıtlar gibi yeni dosya tiplerinin yedeğini almak mümkün olacaktır.

Sürümler ve lisans

Bu yazının yazımı sırasında storeBackup 1.14.1 sürümüne sahipti. Programı http://www.sf.net/projects/storebackup adresinden elde edebilirsiniz.
StoreBackup GPL lisansına sahiptir.

Bu yazı için görüş bildiriminde bulunabilirsiniz

Her yazı kendi görüş bildirim sayfasına sahiptir. Bu sayfaya yorumlarınızı yazabilir ve diğer okuyucuların yorumlarına bakabilirsiniz.

talkback page

<--, Bu sayının ana sayfasına gider

Çeviri bilgisi:

de --> -- : Heinz-Josef Claes <hjclaes(at)web.de>

de --> en: Jürgen Pohl <sept.sapins(at)verizon.net>

en --> tr: Erdal Mutlu <erdal(at)linuxfocus.org>

2004-01-02, generated by lfparser version 2.45

mirror server hosted at Truenetwork, Russian Federation.