Snapshot-Based Data Recovery Approach

Transcription

1 Snapshot-Based Data Recovery Approach Jaechun No College of Electronics and Information Engineering Sejong University 98 Gunja-dong, Gwangjin-gu, Seoul Korea Abstract: - In this paper, we present the design and implementation details of WOWSnap, which is the data backup scheme based on the snapshot approach. As data to be stored in storage subsystems are tremendously increased, data protection techniques have become more important, to provide data availability and reliability. Snapshot is one of such data protection techniques and has been adapted to many file systems. However, in large-scale storage systems, adopting a snapshot technique to prevent data loss from intentional/accidental intrusion is not an easy task because the data size being backup-ed at a given time may be huge. In this paper, we present the WOWSnap that has been implemented based on file system-based snapshot approach. The WOWSnap provides a widely portable structure and causes less I/O processing overhead than ROW (Redirect On Write) method. Furthermore, the WOWSnap provides a capability of maintaining the disk space assigned to snapshot images in a consistently-sized disk portion. We present the performance results of the WOWSnap obtained from the Linux cluster located at Sejong University. Key-Words: - file system-based snapshot, data recovery, WOWSnap, snapshot pointer, spatial algorithm 1 Introduction Many data recovery approaches [9,10,11,12] have been developed to protect important data against system crash. Especially, the snapshot-based data recovery has been adopted to many file systems [5,6,7,8], to provide data availability and reliability. However, in large-scale storage systems, implementing a snapshot technique to prevent data loss against intentional/accidental intrusion is not an easy task, because the data size being backup-ed at a given time may be huge. Simply duplicating the inodes and data blocks associated with a point-intime snapshot causes high I/O processing overhead. Furthermore, maintaining a large number of snapshot images consumes a large portion of disk space. Snapshots can be built in two different ways: one is a volume-based snapshot in which the snapshot images are taken under LVM (Logical Volume Manager), and the other is a file system-based snapshot in which all the snapshot related operations are performed under file system control. Even though the volume-based snapshot can efficiently manage snapshot images and disk space, it requires preserving some disk space for retaining snapshot images. The file system-based snapshot does not need to This paper was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education, Science and Technology ( ). reserve the disk space to store snapshot images. However, because file system-based snapshot is tightly coupled to the underlying file system, porting a snapshot implementation among several file systems would take considerable overhead. Porting a snapshot becomes even worse when file systems that are supposed to use a snapshot support different block allocation policies. We developed the WOWSnap that combines the good features of both file system-based method and ROW approach. Our primary objectives in developing the WOWSnap were to minimize I/O processing overhead to be occurred between successive snapshot images, to provide a wide range of portability by supporting the extent-unit and block-unit allocation policies, and to provide a capability of managing disk space for snapshots in a consistent size of disk section. In order to minimize I/O processing overhead occurred in duplicating inodes and data blocks, we chose to adopt the ROW-based snapshot approach. Besides, we used a pre-allocated metadata to reduce the block allocation time for each instantaneous snapshot. Furthermore, the WOWSnap can be combined with the extent-based storage structure [1,2], as well as be combined with the block-based storage structure [3,4]. When the WOWSnap is combined with the extent-based storage structure, it can detect the sharing of data blocks between several snapshot images, by checking the value of bitmap flag. This ISBN:

2 helps to eliminate the corrupted snapshot images in the snapshot history. The rest of paper is organized as follows: In Section 2, we discuss the design motivations of the WOWSnap. Section 3 describes the implementation details of the WOWSnap and in Section 4, we present the performance results obtained from the Linux cluster at Sejong University. In Section 5, we conclude our paper. 2 Design Motivation In this section, we describe the design motivations of WOWSnap. 2.1 Minimize I/O Overhead In order to minimize I/O processing overhead to be occurred in duplicating inodes and data blocks, we chose to adopt the ROW-based snapshot approach. Additionally, in adopting the ROW approach, we used a pre-allocated metadata to reduce the block allocation time for each instantaneous snapshot. When the inode of an active file is created, we also allocate an additional inode to be used for the following snapshot images. When a point-in-time snapshot is taken, this additional inode becomes an inode of the snapshot file. Also, instead of simply duplicating all the associated blocks of the snapshot file, the snapshot inode just links pointers to the original blocks, to denote that these data blocks are shared between the active file and the snapshot file. In this way, we can significantly reduce the processing time for block allocation, compared to that of COW (Copy On Write) approach. 2.2 Provide Portability The WOWSnap can be combined with the extentbased storage structure where a contiguous number of blocks are allocated to a file segment, as well as can be combined with the block-based storage structure. When the WOWSnap is combined with the extent-based structure, such as XFS [1,2], each inode, including the inode of a snapshot image, contains the extents composed of three components: the starting block address, block count describing the number of blocks contiguously allocated, and bitmap flag describing the sharing of the data blocks belonging to the extent. If the bitmap flag is set to 1, it would then denote that the data blocks belonging to the extent are recently allocated, and thus no other inode currently shares these data blocks yet. If the flag is set to 0, it would then mean that the data blocks belonging to the associated extent are shared between files, thus a careful block management is required while the modification to data blocks happens to these blocks. 2.3 Manage Disk Space for Snapshots We developed a snapshot spatial algorithm that enables us to keep the disk space allocated for snapshot images as smallest as possible. In the WOWSnap, all the snapshot images, including their active file, are grouped by two pointers. In each snapshot group, the active file is linked at the front and the oldest snapshot image is linked at the back. Constructing a snapshot group of an active file enables us to trace back and forth the link, to find which data blocks are shared between files. When the WOWSnap finds corrupted or backup-ed snapshot images while traversing a snapshot group, the snapshot spatial algorithm can check the sharing of the data blocks belonging to those images. It unlinks the associated inode from the snapshot group, and thus keeps snapshot images in a consistently-sized disk section. 3 Implementation Detail In this section, we describe the design and implementation of WOWSnap in details. 3.1 Snapshot Pointer Figure 1. Snapshot Pointer Figure 1 shows the snapshot-related pointers. In order to group snapshot images for an active file, the WOWSnap uses two pointers, prev_core_snap and next_core_snap. By using these two pointers, the snapshot daemon can traverse the history link to verify snapshot integrity. The file linked by the prev_core_snap is a preceding snapshot image, and the file linked with the next_core_snap is either a following snapshot image or an active file. In Figure 1, at t0, an active file is created. At t1, this file becomes the snapshot file, while being linked with its active file by using the ISBN:

3 next_core_snap. When the inode of an active file is created, an additional inode is also pre-allocated and is linked with the active inode using prev_snap_ino. If the next snapshot is taken, then there is no need to allocate and to replicate the inode of the active file because duplicating the inode attributes has already been performed when the extra inode has been preallocated. The only thing to be performed at that moment is to adjust two pointers, prev_core_snap and next_core_snap, and to setup the bitmap value of the extent to indicate the sharing of data blocks. In the WOWSnap, the snapshot daemon periodically issues a snapshot call to check snapshot integrity. 3.2 Overall Structure deletion, because by checking the current bitmap value, the WOWSnap can easily determine whether the data blocks can be updated, or not. If it finds out that the data blocks cannot be modified due to the sharing among multiple files, then it allocates new data blocks to receive the up-to-date value. Also, the extent associated with the data blocks is split to separate the new blocks. Figure 2(c) shows an example where update process is occurred after the first snapshot has been taken. In Figure 2(c), the update requires two blocks, B3 and B4, to be modified. Since these two blocks are shared between the active file and the first snapshot, two new blocks, B5 and B6, are allocated and the update process is performed on these two blocks. Also, to reflect the new block allocation for update, an additional extent is created and its bitmap value is initially set to one, because no other file currently shares these new blocks with the active file. 3.3 Snapshot Spatial Algorithm Figure 2. An overview of snapshot structure The WOWSnap assigns a bitmap value to each extent structure to indicate the sharing of data blocks, as shown in Figure 2(a). If the bitmap value is zero, it then means that the data blocks of the extent cannot be modified because those blocks must be shared with other files. Otherwise, the blocks of the extent can be modified. Figure 2(a) shows an example of the snapshot structure. The file is composed of five data blocks, B0 through B4, and its extent includes three components: the starting block number, block count, and bitmap value. The initial value of the bitmap value is one, meaning that no other file currently shares the data blocks belonging to this file. Figure 2(b) illustrates the steps involved in taking the first snapshot. The file located at the left side denotes an active file and the file at the right side denotes its point-in-time snapshot image. As can be seen in the Figure, the bitmap value of the active file is changed from one to zero because the data blocks of the active file are shared with the first snapshot. Changing the bitmap value has significant performance impact on data modification and Figure 3. Snapshot Spatial Algorithm In the WOWSnap, we provide a snapshot spatial algorithm for consistently maintaining the snapshot history. The spatial algorithm is periodically performed by the snapshot daemon. The daemon is responsible for deleting snapshots, which have been corrupted or backup-ed to other disk. Figures 3(a) and (b) show the steps involved in the snapshot spatial algorithm. Figure 3(a) shows a snapshot overview before eliminating snapshot 2. In the Figure, the first snapshot image, snapshot 1, includes an extent indicating that four data blocks, B0 to B3, are allocated to this image. The second snapshot image, snapshot 2, takes over four blocks from snapshot 1, while changing the bitmap value from one to zero. ISBN:

4 It is noted that when snapshot 2 was the active file, there existed a write operation requesting three new data blocks, B4 to B6, to be allocated. At that moment, the WOWSnap allocated a new extent for these blocks and assigned the bitmap value to one because no block sharing happened yet. Suppose that the snapshot daemon finds out that the second snapshot image, snapshot 2, has been corrupted. The elimination process of the spatial algorithm requires the daemon to traverse prev_core_snap and next_core_snap, to determine if the data blocks belonging to snapshot 2 can be deallocated. With the bitmap value of zero, the blocks belonging to this extent cannot be modified since these blocks are shared with other files linked by the prev_core_snap. On the other hand, with the bitmap value of one, the blocks belonging to this extent are not shared with the preceding snapshots. However, these data blocks might be shared with other following snapshots linked to the next_core_snap. Therefore, the snapshot images linked to the next_core_snap should be checked before deallocating the data blocks belonging to snapshot 2. In Figure 3(b), snapshot 2 has two extents to manage the associated data blocks. Since the bitmap value of the first extent is zero, the corresponding data blocks cannot be de-allocated, thus the spatial algorithm simply unlinks the pointers from those data blocks. The bitmap value of the second extent is one, meaning that the preceding snapshot connected by the prev_core_snap has not shared the data blocks with snapshot 2. However, since these blocks might be shared with the active file, before de-allocating the blocks, the spatial algorithm should check the bitmap value of the active file. Because the active file includes the data blocks being shared with snapshot 2, the spatial algorithm splits the extent into two parts, to separate those blocks. The bitmap value of the first split extent is set to zero because the associated data blocks, B0 to B3, are shared with the first snapshot, snapshot 1. On the other hand, the bitmap value of the second split extent is set to one, because, after eliminating snapshot 2, no other file shares the associated data blocks, B4 to B6, with the active file. 4 Performance Evaluation We obtained all performance results on the Linux cluster at Sejong University. We installed the WOWSnap on top of XFS using the extent-based allocation policy and produced the performance results. Figure 4. Write performance compared to XFS Figure 5. Read performance compared to XFS Figure 6. Rewrite performance compared to XFS Figure 7. Asyc. write performance compared to XFS ISBN:

5 Figures 4 to 7 show the WOWSnap I/O performance with snapshot capability. Also, we compared the performance with XFS[4,5] that does not have snapshot, to find out the effect of snapshot overhead. It is noted that there exists a tradeoff between performance and reliability in using snapshot. We used IOzone benchmark to measure I/O performance. Figure 4 shows the performance of the WOWSnap write operation, while varying the record unit for each file size. Also, we configured the WOWSnap to take a snapshot every one second. In this case, changing the record size for each file size does not lower the write performance as much as we expected. This is because, at each snapshot checkpoint, only the file metadata would be duplicated. Figure 4 also shows the effect of snapshot overhead in the WOWSnap write operations, by comparing I/O performance to that of XFS without snapshot. In case of write operations, the impact of the overhead is obvious, especially in file sizes smaller than 256Mbytes. With small file-sizes, the larger number of snapshot-related metadata operations, such as pre-allocating snapshot inode, would occur than with large file-sizes, thus causing the performance decrement. Figure 5 shows the performance of the WOWSnap read operations, with the impact of memory cache. Unlike in write operations, we can see that using large record size in read operations generate better I/O performance, due to the data coalesce. Also, memory shortage might cause the sharp performance downgrade, with file sizes larger than 512Mbytes. When comparing to XFS read performance, we could see little impact of snapshot overhead. Figure 6 shows the performance of the WOWSnap re-write operations combined with snapshot. In this measurement, after creating each file, the data of record size are re-written in the file. Since the metadata operations for writing files, such as bitmap and block allocation, have been performed before the measurement, the performance of re-write operations is higher than that of write operations in most cases. Also, based on the Figure, we can see that varying the record size does not much affect the performance. In order to see the snapshot overhead in modifying data between checkpoints, we compared the WOWSnap re-write performance to XFS. In rewrite operations, snapshot incurs the related metadata operations, such as inode pre-allocation, snapshot-associated pointer setup, and new block allocation if data modification occurs within the checkpoint. As shown in write operations, with the small file-size, the overhead to create snapshots overwhelms the entire re-write performance because of the large number of snapshots being taken. However, with the file size larger than 128Mbytes, we can see that such a snapshot-related overhead becomes small, thereby the WOWSnap produces better performance than XFS. In this case, even if new block allocations are needed due to data modification, it does not lower the WOWSnap performance. In Figure 7, we measured the effect of simultaneous, multiple I/Os on snapshot. For the performance measurement, we changed the number of threads to 2, 5, and 10, while making them simultaneously access the same file. Since we used a single server which has a single 320Gbytes of disk, we expected that simultaneously accessing with two multiple threads might produce the best I/O performance among three cases, due to the reduced disk contention. However, the result was differently shown. In Figure 7 which measured WOWSnap asynchronous write operations, as both the file size and the number of multiple threads increase, little performance difference is shown before the performance is sharply dropped because of memory shortage. This observation indicates that the increased snapshot overhead because of using larger number of threads does not incur significant performance degradation. 5 Conclusion In this paper, we presented the WOWSnap that combined the good features of both file systembased method and ROW approach. The WOWSnap was designed to minimize I/O processing overhead occurred between successive snapshot images, to provide a wide range of portability by supporting both the extent-based and block-based allocation policies, and to provide a capability of managing disk space for snapshots in a consistent size of disk section. The snapshot performance results show that the impact of the snapshot overhead is obvious with the small file-size because the larger number of snapshot-related metadata operations would occur than with large file-sizes. As a future work, we will justify and improve the performance of the WOWSnap by doing more experiments. References: [1] A. Sweeney, D. Doucette, W. Hu, C. Anderson, M. Nishimoto, and G. Peck, Scalability in the ISBN:

6 XFS File system, USENIX 1996 Annual Technical Conference, [2] J. Mostek, W. Earl, and D. Koren, Porting the SGI XFS File system, Linux 6 th Linux Kongress: The Linux Storage Management Workshop (LSMW), [3] Z.N.J. Peterson, and R.C. Burns, Ext3cow: The design, implementation, and analysis of metadata for a time shifting file system, Technical report, Department of Computer Science, The Johns Hopkins University, [4] Z.N.J. Peterson and R.C. Burns, Ext3cow: A Time-Shifting File System for Regulatory Compliance, ACM Transactions on Storage, 1(2), 2005, pp [5] S. Shim, W. Lee, and C. Park, An Efficient Snapshot Technique for Ext3 File System in Linux 2.6, Technical report, Pohang University of Science and Technology, [6] American Megatrends. Inc., AMI Snapshot Technology, Technical report, [7] B. Mary, and D. Peterson, Integrating Network Appliance Snapshot and SnapRestore with Veritas Netbackup in an Oracle Backup Environment, Technical report 3394, Network Appliance, April 2006 [8] H. Patterson, S. Manley, M. Federwisch, D. Hitz, S. Kleiman, and S. Owara, SnapMirror: File System based Asynchronous Mirroring for Disaster Recovery, Proc. Of the FAST 02 Conference on File and Storage Technologies, Jan., 2002, pp [9] J. Piernas, T. Cortes, and J. Garcia, DualFS: A New Journaling File System without Meta- Data Duplication, Proc. Of the 2002 International Conference on Supercomputing, June [10] M. Seltzer, K. Bostic, M.K. Mckusick, and C. Staelin, An Implementation of a Log- Structured File System for UNIX, USENIX Annual Technical Conference, Jan., [11] D. Santry, M. Feeley, N. Hutchinson, and A. Veitch, Elephant: The File System that Never Forgets, Proc. of IEEE Hot Topics in Operating Systems, March [12] D. Santry, M. Feeley, N. Hutchinson, R. Veitch, R. Carton, and J. Ofir, Deciding when to forget in the Elephant file system, Proc. of 17 th ACM Symposium on Operating Systems Principles (SOSP 99), 34(5), Dec. 1999, pp ISBN: