惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 聂微东
GbyAI
GbyAI
G
Google Developers Blog
大猫的无限游戏
大猫的无限游戏
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园 - 叶小钗
A
About on SuperTechFans
M
MIT News - Artificial intelligence
宝玉的分享
宝玉的分享
雷峰网
雷峰网
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Martin Fowler
Martin Fowler
Google DeepMind News
Google DeepMind News
博客园 - Franky
B
Blog RSS Feed
Y
Y Combinator Blog
Stack Overflow Blog
Stack Overflow Blog
MongoDB | Blog
MongoDB | Blog
Last Week in AI
Last Week in AI
T
The Blog of Author Tim Ferriss
The GitHub Blog
The GitHub Blog
S
SegmentFault 最新的问题
罗磊的独立博客
Apple Machine Learning Research
Apple Machine Learning Research

IT Notes - backup

IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes IT Notes
IT Notes
Stefano Marinelli · 2020-06-28 · via IT Notes - backup

I'm using BTRFS with satisfaction (I mentioned it in 2014 and, more recently, in the IT-Notes blog). I don't consider it optimal for all types of loads, but it solves many problems in many situations. One of the things I use with more satisfaction is the dynamic snapshot generation function, which guarantees the possibility to have a perfect and immediate copy of a specific volume (or subvolume). When a backup is needed, for example, the use of snapshots is fundamental and having them at file system level is undoubtedly a good help.

When it comes to BTRFS volumes, however, we have additional options. There are native tools that are able to send and receive data to and from BTRFS volumes in an optimized way, taking advantage of the inherent features of the file system itself. Here is a method to automatically take snapshots and transfer them to another BTRFS volume (local or remote).

I've been using two interesting scripts for some time now. In the past I used snapper but I didn't find it optimal for my use. I have therefore continued to search and found some valid alternatives, namely the combination of btrfs-snp and btrfs-sync

btrfs-snp

btrfs-snp allows to be launched specifying a path, a prefix linked to the snapshot taken, the maximum number of snapshots with that prefix to hold and a minimum time between snapshots.

For example:

root@foobar:~# /usr/local/sbin/btrfs-snp / hourly 10 3600

It will take a snapshot of /, with the term hourly as prefix (but it can be any prefix), keep a maximum of 10 snapshots and will not take any more (i.e. the program will exit without action) in less than 3600 seconds from the previous one.

You can of course combine them in this way, to have more snapshots of different types:

/usr/local/sbin/btrfs-snp / hourly 10 3600/usr/local/sbin/btrfs-snp / daily 3 86400/usr/local/sbin/btrfs-snp / weekly 1 604800

It can be launched using cron every hour (or every quarter as it will not take a new snapshot if less than 3600 seconds from the previous one have passed).

btrfs-sync

At this point, we can copy all the snapshots to another file system (local or remote) thanks to btrfs-sync.

The command can be of this type:

root@foobar:~# /usr/local/sbin/btrfs-sync -d -v /.snapshots btrfs@host:/backups/host01/

(it's a one line command)

Obviously the destination file system must be a BTRFS volume.

I usually run the command through a script in the cron.daily, to get a daily copy of the snapshots out.

This kind of setup has already got me out of trouble several times and seems to be quite efficient.