Browse Prior Art Database

Modify Frequency Related Incremental Backup

IP.com Disclosure Number: IPCOM000016242D
Original Publication Date: 2002-Sep-30
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 60K

Publishing Venue

IBM

Abstract

Problem

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Modify Frequency Related Incremental Backup

Problem

At the moment, backup software clients do not offer a way to backup files selectively based on file modification frequency. That is, it is not possible to specify a backup for files that have been modified >n times over a specific time interval because frequently modified files are at greater risk of being accidentally lost or corrupted and have, as consequence, a higher probability of needing to be retrieved. This problem arises especially in situations in which bandwidth and/or backup windows constraints exist, or where a policy needs to be implemented by which frequently modified files are backed up to fast access media (e.g. disk), while infrequently modified files are backed up to slower access media (e.g. tape).

Solution

The proposed solution is centred on the creation of a dedicated journal daemon. At the moment, the daemon monitors the journaled filesystem local database for changes since the last backup. To account for the modification frequency count we can modify the daemon to keep trace of how many times a file has been modified since the last backup. According to this frequency number, a specific backup policy will be implemented. Various scenarios are thus enabled: backing up files as soon as they reach a specific modification count, backing up at the scheduled time only those files that have reached the modification count, backing up a specific number of files that have reached the highest modification count or choosing a time interval and backing up those files that have reached a specific modification count in that interval.

Alternative solutions

An alternative solution could be to have the filesystem keep track of the modification frequency. Initially, the value would be 0 when the file is created, and the value would increase by 1 every time the file is changed. The backup software could query this and compare to the previous value when the file was last backed up. Files that have been changed frequently (ie. more than X times in the known backup interval) could have different policies applied. This would require, of course, support from the filesystem developers, and then exploitation by the backup software. Another solution about the limitation of available backup window and resources, and consequent need to backup the most critical files first, could be an include.priority and exclude.priority filters to determine which files are most important, and should be backed up first, then next priority...