Messages in this thread | | | Date | Tue, 25 Jan 2000 12:01:12 +0200 | From | Nimrod Zimerman <> | Subject | Re: inodes are no longer constant across VFAT mounts at kernel 2.2.14 |
| |
On Sun, Jan 23, 2000 at 09:57:37PM -0000, Norman Back wrote:
> However if tar -g had been used instead of tar --newer dir2's contents would > be archived correctly because it checks the name and inode against the > 'snapshot' file. > > Any other sugestions? I don't like the idea of retaining an old version of > kernel simply for archiving. It is possible that some later enhancement of > linux (or fat filestore) will preclude its use in the future.
You could use a "simple" set of scripts to get a statistically current snapshot of the system. It goes something like that (I used an identical scheme to backup my own systems, which used to consist both of ext2 and of fat filesystems):
1. Generate a list of all files on the system, with all the changeable details of them that you care about (filename, symbolic link information, mode, uid, gid, rdev, size, mtime). You can even store an hash of all regular files, if you feel paranoid. To do this, I used 'find' with a perl script.
2. Backup said list of files, and store the list as 'current backup' (I used afio).
3. At some point in time when you wish to make an incremental backup, regenerate the list of files, and figure out what lines appear in the new list but not in the old list (I used 'comm').
4. Backup the new list of files, and store the list along with the original list as 'incremental backup i'.
5. Repeat from stage 3 ad infinitum.
There probably are publicly available scripts that do this same thing, by the way. I'm certain I didn't invent anything...
My set of scripts are in a terribly fuzzy state, especially as I didn't use them for quite some time. If you ask, I can send them to you (after proper removal of embarrassing parts).
Nimrod
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |