1.建立快照:
lvcreate --size 100m --snapshot --name mdb-snap01 /dev/vg0/mongodb
因為是增量快照,100m是diff的大小.
2.mount快照卷後,就開始拷貝了.採用寫時定向(cow)
我猜測: 快照生成後,原始卷對應塊的修改,應該是生成新的block,而舊的block因為有快照引用不會被刪除.
3.快照存檔
存檔時umount,然後dd,gzip:
umount /dev/vg0/mdb-snap01dd if
=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz
在mongo或mysql使用過程中,只要乙個讀鎖,然後flush相應改動,建立實時快照,釋放讀鎖,很短的時間就完成備份,對線上服務影響比較小.
不過我在微博上也看到乙個關於效能的:
特里王：某同事說他盡量避免使用 lvm 因為他做過一些測試得出的結論是相對於塊裝置上的同種檔案系統 lvm2 有近40%的額外效能開銷。這與我所知相差甚遠：效能損失相對於其靈活性可以忽略。研究後發現真有此事，有無快照對邏輯卷 i/o 效能影響巨大（和 copy on write 有關），非得用快照的話 chunksize 越大越好
所以為了避免造成效能下降,快照卷要即時存檔釋放.
vmware,kvm裡的快照映象用的就是類似技術.
有時間應該動手做一次,要搞清楚何時停止快照.是在lvcreate還是umount的時候呢?
參考:
mysql資料庫基於LVM快照的備份
lvm snapshot 基於lvm快照的備份 1.事務日誌跟資料檔案必須在同乙個卷上 2.建立快照卷之前，要請求mysql的全域性鎖，在快照建立完成之後釋放鎖 3.在請求全域性鎖完成之後，做一次日誌滾動 做二進位制日誌檔案及位置標記 手動進行 步驟 1.請求全域性鎖，並滾動日誌 mysql flu...
mysql資料庫基於LVM快照的備份
lvm snapshot 基於lvm快照的備份 1.事務日誌跟資料檔案必須在同乙個卷上 2.建立快照卷之前，要請求mysql的全域性鎖，在快照建立完成之後釋放鎖 3.在請求全域性鎖完成之後，做一次日誌滾動 做二進位制日誌檔案及位置標記 手動進行 步驟 1.請求全域性鎖，並滾動日誌 mysql flu...
rbd通過快照進行卷備份
rbd的增量備份和恢復 快照的功能一般是基於時間點做乙個標記，然後在某些需要的時候，將狀態恢復到標記的那個點，這個有乙個前提是底層的東西沒用破壞，舉個簡單的例子，vmware裡面對虛擬機器做了乙個快照，然後做了一些系統的操作，想恢復快照，前提是儲存快照的儲存系統沒用破壞，一旦破壞了是無法恢復的 1....