[深入理解文件系统之十三] 基于快照的文件系统备份

简介:

在实际生产系统上存储的数据,都是基于某种文件系统的形式组织、存放起来的。对一些关键的数据,就需要备份。通常,有两种方式:

1.基于Linux/unix下的tar/cpio等工具

虽然它也能实现备份,但不足之处在于有IO写入的情况下,可能无法保证文件系统的integrity (完整性).


2. frozen-image 

虽然备份的时候停下业务、卸载 文件系统就可以了,但是系统管理员一般不愿意停下业务、或者卸载文件系统,因此stable snapshot技术出现了。(snapshot/frozen-image/point-in-time都是指文件系统中的stable image).根据重启之后,数据是否还一直,snapshot可以分为non persistent snapshot  和persistent snapshot。


下面基于VxFS文件想,介绍一下snapshot的使用示例:

#vxassist make fs1 100m

#mkfs -F vxfs /dev/vx/rdsk/fs1 100m

version 4 layout

204800 sectors, 102400 blocks of size 1024, log size 1024 blocks

unlimited inodes, largefiles not supported

102400 data blocks, 101280 free data blocks

4 allocation units of 32768 blocks, 32768 data blocks

last allocation unit has 4096 data blocks

#mount -F vxfs /dev/vx/dsk/fs1 /fs1

#echo hello > /fs1/fileA

#echo goodbye > /fs1/fileB

#mkdir /snap

#vxassist make snap 10m

#mount -F vxfs -osnapof=/fs1,snapsize=20480 /dev/vx/dsk/snap /snap  #建立快照

#df -k

...

/dev/vx/dsk/fs1 102400 1135 94943 2% /fs1

/dev/vx/dsk/snap 102400 1135 94936 2% /snap

...

#ls -l /fs1

total 4

-rw-r--r-- 1 root other 6 Jun 7 11:17 fileA

-rw-r--r-- 1 root other 8 Jun 7 11:17 fileB

drwxr-xr-x 2 root root 96 Jun 7 11:15 lost+found

#ls -l /snap

total 4

-rw-r--r-- 1 root other 6 Jun 7 11:17 fileA

-rw-r--r-- 1 root other 8 Jun 7 11:17 fileB

drwxr-xr-x 2 root root 96 Jun 7 11:15 lost+found

#cat /fs1/fileA

hello

#cat /snap/fileA

hello

#rm /fs1/fileA

# cat /snap/fileA

hello

#df -k

...

/dev/vx/dsk/fs1 102400 1134 94944 2% /fs1

/dev/vx/dsk/snap 102400 1135 94936 2% /snap


然后,用户可以利用快照进行备份,在VxFS中可以利用fscat(类似于linux中的dd命令):

#vxassist make fs1 10m

#vxassist make fs1-copy 10m

#vxassist make snap 5m

#mkfs -F vxfs /dev/vx/rdsk/fs1 10m

version 4 layout

20480 sectors, 10240 blocks of size 1024, log size 1024 blocks

unlimited inodes, largefiles not supported

10240 data blocks, 9144 free data blocks

1 allocation units of 32768 blocks, 32768 data blocks

last allocation unit has 10240 data blocks

#mount -F vxfs /dev/vx/dsk/fs1 /fs1

#echo hello > /fs1/hello

#echo goodbye > /fs1/goodbye

#mount -F vxfs -osnapof=/fs1,snapsize=10240 /dev/vx/dsk/snap /snap

#rm /fs1/hello

#rm /fs1/goodbye

#fscat /dev/vx/dsk/snap > /dev/vx/rdsk/fs1-copy #场景快照snap的备份,文件系统名称是fs1-copy


删除fs1/hello和fs1/goodbye之后,snap文件中的super block中的dirty位被设置起来,因此后面他的备份文件系统fs1-copy中的dirty-bit也处于置位状态,在fs1-copy被挂载的时候就会重放出之前的文件:

# fsck -F vxfs /dev/vx/rdsk/fs1-copy

log replay in progress

replay complete - marking super-block as CLEAN

#mount -F vxfs /dev/vx/dsk/fs1-copy /fs2

#ls -l /fs2

total 4

-rw-r--r-- 1 root other 8 Jun 7 11:37 goodbye

-rw-r--r-- 1 root other 6 Jun 7 11:37 hello

drwxr-xr-x 2 root root 96 Jun 7 11:37 lost+found

#cat /fs2/hello

hello

#cat /fs2/goodbye

goodbye


VxFS中snapshot的实现


wKiom1j-3BbTVACrAABB9odA8Wk187.png

在VxFS里,这些snapshot只是在文件系统被挂载或运行的时候,里面的数据才会存在,因此是non-persistent的。为了改进这个问题,VxFS引入了checkpoints的概念。两者的区别如下表:




wKiom1j-3JuRx1q6AABIuYs8Txk802.png

Non-persistent snapshot 只有只读属性的原因是,它的bitmap只记录了变化的block,如果读的话,现有的数据结构(设计)无法支持。


VxFS中checkpoints的用法示例:

#mkfs -F vxfs /dev/vx/rdsk/fs1 100m

version 4 layout

204800 sectors, 102400 blocks of size 1024, log size 1024 blocks

unlimited inodes, largefiles not supported

102400 data blocks, 101280 free data blocks

4 allocation units of 32768 blocks, 32768 data blocks

last allocation unit has 4096 data blocks

#mount -F vxfs /dev/vx/dsk/fs1 /fs1

#echo hello > /fs1/hello

#echo goodbye > /fs1/goodbye

#ls -l /fs1

total 4

-rw-r--r-- 1 root other 8 Jun 9 11:05 goodbye

-rw-r--r-- 1 root other 6 Jun 9 11:05 hello

drwxr-xr-x 2 root root 96 Jun 9 11:04 lost+found

#fsckptadm create ckpt1 /fs1   #创建checkponts1

#rm /fs1/goodbye

#echo "hello again" > /fs1/hello

#fsckptadm create ckpt2 /fs1 #创建checkponts2

#fsckptadm list /fs1

/fs1

ckpt2:

ctime = Sun Jun 9 11:06:55 2002

mtme = Sun Jun 9 11:06:55 2002

flags = none

ckpt1:

ctime = Sun Jun 9 11:05:48 2002

mtime = Sun Jun 9 11:05:48 2002

flags = none

#mkdir /ckpt1

#mkdir /ckpt2

#mount -F vxfs -ockpt=ckpt1 /dev/vx/dsk/fs1:ckpt1 /ckpt1

#mount -F vxfs -ockpt=ckpt2 /dev/vx/dsk/fs1:ckpt2 /ckpt2

#ls -l /fs1

total 2

-rw-r--r-- 1 root other 12 Jun 9 11:06 hello

drwxr-xr-x 2 root root 96 Jun 9 11:04 lost+found

#ls -l /ckpt1

total 4

-rw-r--r-- 1 root other 8 Jun 9 11:05 goodbye

-rw-r--r-- 1 root other 6 Jun 9 11:05 hello

drwxr-xr-x 2 root root 96 Jun 9 11:04 lost+found

#ls -l /ckpt2

total 0

-rw-r--r-- 1 root other 12 Jun 9 11:06 hello

drwxr-xr-x 2 root root 96 Jun 9 11:04 lost+found


VxFS中checkpoints的实现:(复制indoe/file descriptor)


VxFS storage checkpoints are heavily tied to the implementation of VxFS. The

sectionVxFS Disk Layout Version 5, in Chapter 9, describes the various

components of the VxFS disk layout. VxFS mountable entities are called filesets.

Each fileset has its own inode list including an inode for the root of the fileset,

allowing it to be mounted separately from other filesets. By providing linkage

between the two filesets, VxFS uses this mechanism to construct a chain of

checkpoints, as shown in Figure 12.4.

This linkage is called a clone chain. At the head of the clone chain is the primary

fileset. When a filesystem is created with mkfs, only the primary fileset is created.

When a checkpoint is created, the following events occur:

■ A new fileset header entry is created and linked into the clone chain. The

primary fileset will point downstream to the new checkpoint, and the new

checkpoint will point downstream to the next most recent checkpoint.

Upstream linkages will be set in the reverse direction. The downstream

pointer of the oldest checkpoint will be NULL to indicate that it is the

oldest fileset in the clone chain.

■ An inode list is created. Each inode in the new checkpoint is an exact copy

of the inode in the primary fileset with the exception of the block map.

When the checkpoint is created, inodes are said to be fully overlayed. In

order to read any data from the inode, the filesystem must walk up the

clone chain to read the blocks from the inode upstream.

■ The in-core fileset structures are modified to take into account the new

checkpoint. This is mainly to link the new fileset into the clone chain.


下面是主要的数据结构关联图:


wKioL1j-3OXjo4K_AABRwFReyC8032.png

















本文转自存储之厨51CTO博客,原文链接:http://blog.51cto.com/xiamachao/1919187 ,如需转载请自行联系原作者




相关文章
|
4月前
|
存储
【北亚服务器数据恢复】ZFS文件系统服务器无法进入系统的数据恢复案例
服务器数据恢复环境: 服务器中有32块硬盘,组建了3组RAIDZ,部分磁盘作为热备盘。zfs文件系统。 服务器故障: 服务器运行中突然崩溃,排除断电、进水、异常操作等外部因素。工作人员将服务器重启后发现无法进入操作系统。
【北亚服务器数据恢复】ZFS文件系统服务器无法进入系统的数据恢复案例
|
5月前
|
存储 算法 数据挖掘
服务器数据恢复—Zfs文件系统误删除文件的数据恢复案例
一台zfs文件系统服务器,管理员误操作删除服务器上的数据。
服务器数据恢复—Zfs文件系统误删除文件的数据恢复案例
|
7月前
|
存储 数据挖掘 Windows
服务器数据恢复-zfs文件系统服务器raidz数据恢复案例
服务器数据恢复环境: 一台服务器共配备32块硬盘,组建了4组RAIDZ,Windows操作系统+zfs文件系统。 服务器故障: 服务器在运行过程中突然崩溃,经过初步检测检测没有发现服务器存在物理故障,重启服务器后故障依旧,需要恢复服务器内的大量数据。
服务器数据恢复-zfs文件系统服务器raidz数据恢复案例
|
7月前
|
存储 算法 安全
文件系统管理:挂载、格式化、备份和修复你的文件系统
文件系统管理:挂载、格式化、备份和修复你的文件系统
63 0
|
3月前
|
存储 Oracle 关系型数据库
【北亚企安数据恢复】服务器ZFS文件系统数据恢复案例
服务器数据恢复环境: ORACLE SUN ZFS某型号存储,共40块磁盘组建存储池,其中的36块磁盘分为三组,每组12块,单个组使用ZFS特有的RAIDZ管理所有磁盘,RAIDZ级别为2;另外的4块磁盘作为全局热备。存储池内划分出若干空间映射到服务器使用。 服务器故障: 服务器正常运行过程中崩溃,服务器管理员重启设备后无法进入系统。通过对服务器和存储的初步检测以及和管理人员的沟通,排除了断电、进水、异常操作等外部因素。
【北亚企安数据恢复】服务器ZFS文件系统数据恢复案例
|
4月前
|
存储 监控 安全
文件备份系统
文件备份系统
86 1
|
4月前
|
数据挖掘 Linux
服务器数据恢复—XFS文件系统服务器数据恢复案例
服务器数据恢复环境: 服务器使用磁盘柜+RAID卡搭建了一组riad5磁盘阵列。服务器上层分配了一个LUN,划分了两个分区:sdc1分区和sdc2分区。通过LVM扩容的方式,将sdc1分区加入到了root_lv中;sdc2分区格式化为XFS文件系统。服务器安装的Linux系统。 服务器故障: 服务器重装操作系统后sdc磁盘分区发生改变,原sdc2分区丢失,无法访问。
服务器数据恢复—XFS文件系统服务器数据恢复案例
|
4月前
|
存储 数据挖掘 数据库
服务器数据恢复—ocfs2文件系统数据恢复案例
由于工作人员的误操作,将Ext4文件系统误装入到存储中Ocfs2文件系统数据卷上,导致原Ocfs2文件系统被格式化为Ext4文件系统。 由于Ext4文件系统每隔几百兆就会写入文件系统的原始信息,原Ocfs2文件系统数据会遭受一定程度的破坏,但破坏的应该不太多。
服务器数据恢复—ocfs2文件系统数据恢复案例
|
7月前
|
存储 Oracle 关系型数据库
服务器数据恢复-LINUX下误删除/格式化的数据恢复方案
服务器数据恢复环境: 基于EXT2/EXT3/EXT4/Reiserfs/Xfs文件系统的Linux操作系统。 服务器故障: LINUX操作系统下误删除/格式化数据。
服务器数据恢复-LINUX下误删除/格式化的数据恢复方案
|
弹性计算 Linux
快照创建的磁盘挂载提示文件系统错误
快照创建的磁盘挂载提示文件系统错误

相关实验场景

更多