You can restore the state of the drive to an arbitrary time in the past by replaying past writes.
For example, suppose something bad happens (a bug deletes important files, someone installs ransomware, etc) and you want to roll back the system three days.
Restore the last full backup you have that is older than the desired rollback time. Then replay from the write log every write that occurred between the time of that backup and the time you are trying to rollback to.
Another use for it is restoring or reverting files that were originally created more recently than your last regular (full or incremental) backup.
Example: I do incremental cloud backups once a week, on Saturday. Suppose I create a file on Monday, make various changes to it on Tuesday and Wednesday, accidentally delete it or corrupt it on Thursday, and realize this on Friday and want to recover the file.
With the "every write" log, I could find the file in the write log and recover it.
You might at first think that I would not be able to find it because unlike most backup programs the write log does not explicitly record file information. But it doesn't have to explicitly record file information because when you create a file or modify it the OS stores that information by writingtothedisk, and those writes end up in your tape write log.
If I'm trying to restore /home/tzs/important_file to the state it was two days ago, the restore process would scan the write log starting far enough back to find the latest earlier write of the root inode (let's assume it was a classic Unix filesystem). Once it has that it can find /home's inode, then can find the correct contents of that on the target date, and so on until it has the inode of important_file. Then it can find what blocks comprised the file, and pull the right versions of those blocks from the write log.
Note that for this to work, the restore program must intimately understand the filesystem whose write log it is working with. This is one of the reasons you want to still do a more normal full/incremental period backup system with a backup program that explicitly stores files. The write log is best used to supplement the traditional approach.
PS: there was a backup program in whatever AT&T Unix was current in the early '80s (System III) that used the write log approach, although it was not continuous and it wrote redundant data. It was used for incremental backups. You started with a full block level backup. Then when you wanted to do an incremental backup it did this:
1. Make an empty list of blocks.
2. Add the block number of the superblock to the list.
3. Scan all the inodes looking for any inode that has a create or modify time later than the previous backup. For any such inode:
3a. Add the number of the block that contains that inode to the list.
3b. Add the block numbers of the file that the inode refers to to the list, including any indirect blocks.
4. Sort the block number list.
5. Copy all the blocks that are referenced in the list to the tape.
(There was probably a "write some metadata about the backup to the tape" step in there somewhere, too).
Note that this approach was redundant, in that if you changed part of a file the whole file would be written to the incremental backup. A pure write log would only write the changed blocks, but most systems don't record sufficiently granular modification information to allow that.
On the plus side, it meant that restoring a file from an incremental backup was easy. The file was either in that incremental entirely or not at all.
For example, suppose something bad happens (a bug deletes important files, someone installs ransomware, etc) and you want to roll back the system three days.
Restore the last full backup you have that is older than the desired rollback time. Then replay from the write log every write that occurred between the time of that backup and the time you are trying to rollback to.
Another use for it is restoring or reverting files that were originally created more recently than your last regular (full or incremental) backup.
Example: I do incremental cloud backups once a week, on Saturday. Suppose I create a file on Monday, make various changes to it on Tuesday and Wednesday, accidentally delete it or corrupt it on Thursday, and realize this on Friday and want to recover the file.
With the "every write" log, I could find the file in the write log and recover it.
You might at first think that I would not be able to find it because unlike most backup programs the write log does not explicitly record file information. But it doesn't have to explicitly record file information because when you create a file or modify it the OS stores that information by writing to the disk, and those writes end up in your tape write log.
If I'm trying to restore /home/tzs/important_file to the state it was two days ago, the restore process would scan the write log starting far enough back to find the latest earlier write of the root inode (let's assume it was a classic Unix filesystem). Once it has that it can find /home's inode, then can find the correct contents of that on the target date, and so on until it has the inode of important_file. Then it can find what blocks comprised the file, and pull the right versions of those blocks from the write log.
Note that for this to work, the restore program must intimately understand the filesystem whose write log it is working with. This is one of the reasons you want to still do a more normal full/incremental period backup system with a backup program that explicitly stores files. The write log is best used to supplement the traditional approach.
PS: there was a backup program in whatever AT&T Unix was current in the early '80s (System III) that used the write log approach, although it was not continuous and it wrote redundant data. It was used for incremental backups. You started with a full block level backup. Then when you wanted to do an incremental backup it did this:
1. Make an empty list of blocks.
2. Add the block number of the superblock to the list.
3. Scan all the inodes looking for any inode that has a create or modify time later than the previous backup. For any such inode:
3a. Add the number of the block that contains that inode to the list.
3b. Add the block numbers of the file that the inode refers to to the list, including any indirect blocks.
4. Sort the block number list.
5. Copy all the blocks that are referenced in the list to the tape.
(There was probably a "write some metadata about the backup to the tape" step in there somewhere, too).
Note that this approach was redundant, in that if you changed part of a file the whole file would be written to the incremental backup. A pure write log would only write the changed blocks, but most systems don't record sufficiently granular modification information to allow that.
On the plus side, it meant that restoring a file from an incremental backup was easy. The file was either in that incremental entirely or not at all.