Bu yazıda Backup, Restore, Merge Backup ve Restore Backup işlemlerini anlatacağım.
Couchbase, Backup ve Restore işlemleri için bir kaç farklı tool sunmaktadır.
Bunlar cbbackmgr, cbbackup ve cbrestore toollarıdır.
cbbackmgr ;
Couchbase Backup Manager, yalnızca Couchbase Server Enterprise Edition’da bulunan kurumsal düzeyde bir backup ve restore yardımcı programıdır. Enterprise Edition için tasarlanan bu sürüm, cbbackup ve cbrestore araçlarını, 4.5 sürümü ve üstü sürümlerden Enterprise müşterileri için birincil ve önerilen yedekleme ve geri yükleme aracı olarak değiştirir. Data, index ve bucket yapılandırmalarının önceki nesil araçlara göre önemli ölçüde artırılmış bir hızda yedeklenmesini ve geri yüklenmesini sağlar. Tüm yedeklemeler active olarak çalışan clusterlarda gerçekleştirilebilir.
cbbackup ve cbrestore ;
Cbbackup ve cbrestore araçları, Couchbase Server’a basit ama etkili yedekleme ve geri yükleme özellikleri sağlar. Cbbackup aracı tek bir node’u, single bucketları veya clusterın tamamını esnek bir yedekleme yapısına dahil ederek yedeklemenizi sağlar. Cbrestore aracı, verileri aynı veya farklı bucketlara veya clusterlara geri yüklemeyi sağlayabilir.
Backup Configuration
Cbbackupmgr ile çalışmaya başlamadan önce, tüm backupların tutulacağı dizine karar vermelisiniz. Bu dizine backup archive (yedekleme arşivi) denir. Yedekleme arşivi bir veya daha fazla yedek veri havuzu (reposity) içerir. Bu yedekleme havuzları, backuplarınızın bulunduğu yerdir. Bir yedek havuzu mantığını düşünmenin en kolay yolu, doğrudan yedeklemek istediğiniz tek bir cluster’a karşılık geleceği şekildedir. Yedekleme havuzu ayrıca cluster’ın nasıl geri ayağa kalkması gerektiği bilgisini içeren bir configuration’a sahiptir.
Bu yazıda /data/backup dizini altındaki configurationlara göz atarak, yeni bir backup almayı inceleyeceğiz. Belirtilen dizin boşsa yedekleme arşivi otomatik olarak oluşturulur. Aşağıda, hedef kümedeki tüm bölümlerden tüm verileri ve dizin tanımlarını yedekleyecek “cluster” adlı bir yedekleme havuzunun nasıl oluşturulacağına ilişkin bir örnek verilmiştir.
$ cbbackupmgr config -a /data/backup -r cluster
Backup repository `cluster` created successfully in archive `/data/backup`
Yedekleme havuzu oluşturma işleminin en önemli yönlerinden biri, her bir yedekleme deposundaki yedeklemelerin alınma biçimini değiştirmek için bu yedekleme havuzunu birçok farklı şekilde yapılandırabilmemizdir. Diyelim ki yalnızca travel-sample bucket’ının ayrı bir yedeklemesini istiyoruz. Bunu yapmak için “single” adlı ayrı bir yedekleme havuzu oluşturabiliriz.
$ cbbackupmgr config -a /data/backup -r single \ --include-buckets travel-sample --disable-data
Backup repository `single` created successfully in archive `/data/backup`
Backup Cluster
Şimdi bazı yedekleme depoları oluşturduğumuza göre, nasıl göründüğünü görmek için yedekleme arşivimize bakmalıyız. Bunu yapmanın en kolay yolu liste alt komutunu kullanmaktır. Bu alt komut bir yedekleme arşivini incelemek için kullanılır ve içinde ne kadar veri depolandığı hakkında bilgi verir. Yedekleme arşivinin tamamını görmek için aşağıdaki komutu çalıştırabiliriz.
$ cbbackupmgr list -a /data/backup
Size Items Name 0B - / 0B - + cluster 0B - + single
Liste alt komutu bize yedekleme arşivindeki tüm yedekleme havuzlarından ve yedeklemelerden bir dizin yazdırması sağlar. Hiçbir yedekleme olmadığından, bu komutun çıktısında arşiv listemizi görebiliriz. Ayrıca, her klasör ve dosyanın ne kadar disk alanı içerdiği ve varsa, bu klasörlerde / dosyalarda kaç öğenin yedeklendiği hakkında bilgi de vardır. Liste alt komutu hakkında daha fazla bilgi cbbackupmgr-list sayfasında bulunabilir.
Artık yedekleme havuzlarımızı yapılandırdığımız için yedek almaya başlayabiliriz. Yedek deposu, yedeklemenin nasıl alınması gerektiğine ilişkin tüm yapılandırma bilgilerini içerdiğinden, yalnızca yedek havuz adını ve yedeklemek istediğimiz hedef küme bilgilerini belirtmemiz yeterli olacaktır. Aşağıda, “cluster” yedekleme havuzunda nasıl yedek alınacağına ilişkin bir örnek mevcuttur. Kümemizin localhost üzerinde çalıştığını varsayarak;
$ cbbackupmgr backup -a /data/backup -r cluster \ -c couchbase://127.0.0.1 -u Administrator -p password
Backing up to 2016-03-22T10_26_08.933579821-07_00 Copied all data in 6s (Avg. 6.67MB/Sec) 38894 items / 40.02MB travel-sample [==================================] 100.00% beer-sample [==================================] 100.00%
Backup successfully completed
Backup komutu çalıştırıldığında, varsayılan olarak yedeklemenizin ne kadar sürede tamamlanacağını ve veri taşıma hızını anlamak için yardımcı olan bir process bar göreceksiniz. Yedekleme çalışırken process bar, tahmini olarak bir backup tamamlama süresi verecektir. Yedekleme başarıyla tamamlanırsa, yazdırılan son satırda “Backup successfully completed” yazısını görürsünüz.
İki yedeklemenin nasıl farklı olduğunu görmek için yedeklemeyi “single” yedekleme deposunda da çalıştıralım.
$ cbbackupmgr backup -a /data/backup -r single \ -c couchbase://127.0.0.1 -u Administrator -p password
Backing up to 2016-03-22T10_33_20.812668465-07_00 Copied all data in 1s (Avg. 480B/Sec) 0 items / 480B travel-sample [==================================] 100.00%
“single” yedekleme deposu yalnızca travel-sample bucket’ı için dizin tanımlarını yedeklemek üzere yapılandırıldığından, beer-sample bucket’ı için bir ilerleme çubuğu görmüyoruz. Ayrıca, yedeklenecek çok daha az veri olduğundan yedeklemenin daha hızlı yürütüldüğünü de görebiliriz.
Artık yedekleme arşivimizde yedekler bulunduğundan, yedek arşivimizin durumunun alt listeyi kullanarak nasıl değiştiğine bakalım.
$ cbbackupmgr list -a /data/backup
Size Items Name 154.25MB - / 154.21MB - + cluster 154.21MB - + 2016-03-22T10_26_08.933579821-07_00 55.85MB - + beer-sample 298B 0 bucket-config.json 55.84MB 7303 + data 55.84MB 7303 shard_0.fdb 2B 0 full-text.json 10.07KB 8 gsi.json 784B 1 views.json 98.36MB - + travel-sample 300B 0 bucket-config.json 98.35MB 31591 + data 98.35MB 31591 shard_0.fdb 2B 0 full-text.json 10.07KB 8 gsi.json 1.72KB 1 views.json 40.08KB - + single 40.08KB - + 2016-03-22T10_33_20.812668465-07_00 40.08KB - + travel-sample 300B 0 bucket-config.json 28.00KB 0 + data 28.00KB 0 shard_0.fdb 2B 0 full-text.json 10.07KB 8 gsi.json 1.72KB 1 views.json
“Küme” yedekleme havuzumuzda, yedeklemenin alındığı zamana karşılık gelen bir ad içeren bir yedekleme bulunduğunu görebiliriz. Bu yedekleme ayrıca iki bucket içerir ve bu yedeklemelerin her birinde boyut ve öğe sayılarıyla birlikte çeşitli dosyalar görebiliriz. “single” yedek veri havuzu da bir yedek mevcut, ancak bu yedek yalnızca travel-sample bucket’ını içerir ve 0 veri öğesi barındırır.
Cbbackupmgr’nin en önemli özelliklerinden biri, yalnızca incremental-only bir yedekleme yardımcı programı olmasıdır. Bu, bazı verileri yedeklediğimizde, bir daha asla yedeklememiz gerekmeyeceği anlamına gelir. Kümedeki bazı değişiklikleri simüle etmek için, 02-modify.sh komut dosyasını öğreticinin başında belirtilen yedekleme öğretici github deposundan çalıştırabiliriz. Bu komut dosyasına sahip değilseniz, travel-sample bucket’nda iki belgeyi değiştirmeniz ve iki yeni belge eklemeniz gerekir. Bazı verileri değiştirdikten sonra “cluster” yedekleme deposunda yedekleme alt komutunu yeniden çalıştıracağız.
$ cbbackupmgr backup -a /data/backup -r cluster \ -c couchbase://127.0.0.1 -u Administrator -p password
Backing up to 2016-03-22T14_00_38.668068342-07_00 Copied all data in 3s (Avg. 18.98KB/Sec) 4 items / 56.95KB travel-sample [==================================] 100.00% beer-sample [==================================] 100.00%
Backup successfully completed
Yedekleme arşivini list alt komutunu kullanarak listelersek, yedekleme arşivinin aşağıdaki gibi bir şeye benzediğini göreceğiz.
$ cbbackupmgr list -a /data/backup
Size Items Name 254.31MB - / 254.28MB - + cluster 154.19MB - + 2016-03-22T10_26_08.933579821-07_00 55.84MB - + beer-sample 298B 0 bucket-config.json 55.83MB 7303 + data 55.83MB 7303 shard_0.fdb 2B 0 full-text.json 9.99KB 8 gsi.json 784B 1 views.json 98.35MB - + travel-sample 300B 0 bucket-config.json 98.34MB 31591 + data 98.34MB 31591 shard_0.fdb 2B 0 full-text.json 9.99KB 8 gsi.json 1.72KB 1 views.json 100.08MB - + 2016-03-22T14_00_38.668068342-07_00 50.03MB - + beer-sample 298B 0 bucket-config.json 50.02MB 0 + data 50.02MB 0 shard_0.fdb 2B 0 full-text.json 9.99KB 8 gsi.json 784B 1 views.json 50.05MB - + travel-sample 300B 0 bucket-config.json 50.04MB 4 + data 50.04MB 4 shard_0.fdb 2B 0 full-text.json 9.99KB 8 gsi.json 1.72KB 1 views.json 40.08KB - + single 40.08KB - + 2016-03-22T10_33_20.812668465-07_00 40.08KB - + travel-sample 300B 0 bucket-config.json 28.00KB 0 + data 28.00KB 0 shard_0.fdb 2B 0 full-text.json 10.07KB 8 gsi.json 1.72KB 1 views.json
Restore Backup
Şimdi bazı backup dosyalarımız olduğuna göre, bu backup dosyalarından cluster’a bir restore işlemi yapabiliriz. Verileri geri yüklemek için sadece geri yüklemek istediğimiz yedeklemenin adını bilmemiz gerekir. Adı bulmak için, yedek arşivimizde ne olduğunu görmek için liste alt komutunu tekrar kullanabiliriz. Yedek adında bir zaman damgası olacaktır. Örneğin, 2016-03-22T10_26_08.933579821-07_00 ürününü “cluter” yedek havuzundan geri yüklemek istediğimizi varsayalım. Bunu yapmak için aşağıdaki komutu çalıştırıyoruz.
$ cbbackupmgr restore -a /tmp/backup -r cluster \ -c http://127.0.0.1:8091 -u Administrator -p password \ --start 2016-03-22T14_00_16.892277632-07_00 \ --end 2016-03-22T14_00_16.892277632-07_00 --force-updates
(1/1) Restoring backup 2016-03-22T14_00_16.892277632-07_00 Copied all data in 2s (Avg. 19.96MB/Sec) 38894 items / 39.91MB travel-sample [==================================] 100.00% beer-sample
Restore completed successfully
Yukarıdaki komutta, geri yüklemek istediğimiz yedekleme aralığını belirtmek için –start ve –end parametrelerini kullanıyoruz. Yalnızca bir yedeklemeyi geri yüklediğimiz için –start ve –end için aynı değeri belirlerdik. Couchbase’de çakışma problemini atlamak için –force-updates parametresini ekledik. Kümede güncellediğimiz iki değere bakarsak, şimdi ilk yedeklemeyi aldığımız zamanki haline geri döndüklerini göreceğiz.
Merge Backup
Incremental backup ile yedek almak, aldığımız her yedeklemenin disk alanını artırdığı anlamına gelir. Disk alanı sonsuz olmadığından, bu disk alanını geri kazanabilmemiz gerekir. Bunu yapmak için iki veya daha fazla yedeklemeyi birleştirmek için cbbackupmgr-merge alt komutunu kullanırız. “cluster” yedekleme havuzunda iki backup olduğundan, aşağıdaki komutu kullanarak bu backupları bir araya getireceğiz.
$ cbbackupmgr merge -a /data/backup -r cluster \ --start 2016-03-22T14_00_16.892277632-07_00 \ --end 2016-03-22T14_00_38.668068342-07_00
Merge completed successfully
Yedekleri bir araya getirdikten sonra, tekrardan liste komutu ile yedeklerin son durumuna bakalım.
$ cbbackupmgr list --archive /data/backup Size Items Name 154.41MB - / 154.37MB - + cluster 154.37MB - + 2016-03-22T14_00_38.668068342-07_00 55.84MB - + beer-sample 298B 0 bucket-config.json 55.83MB 7303 + data 55.83MB 7303 shard_0.fdb 2B 0 full-text.json 9.99KB 8 gsi.json 784B 1 views.json 98.53MB - + travel-sample 300B 0 bucket-config.json 98.52MB 31593 + data 98.52MB 31593 shard_0.fdb 2B 0 full-text.json 9.99KB 8 gsi.json 1.72KB 1 views.json 40.08KB - + single 40.08KB - + 2016-03-22T10_33_20.812668465-07_00 40.08KB - + travel-sample 300B 0 bucket-config.json 28.00KB 0 + data 28.00KB 0 shard_0.fdb 2B 0 full-text.json 10.07KB 8 gsi.json 1.72KB 1 views.json
Remove Backup
Eğer yedek dosyalarınıza artık ihtiyacınız yoksa alltaki komut ile yedeklerinizi tamamen silebilirsiniz.
$ cbbackupmgr remove -a /data/backup -r cluster
Backup repository `cluster` deleted successfully from archive `/data/backup`
