Hi, I'm trying to use your app to take continuously updated images of windows boot drives on a daily basis. For my use case an ideal backup would be a "raw", full disk copy taken off of a VSS snapshot, however enabling VSS seems to automatically enable the usedblocks feature. Would it be possible to enable snapshots without enabling the UsedBlocks feature, similar to the raw mode of driveimage xml?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's an interesting question. I thought about offering this option but came to the conclusion that it doesn't make much sense. The VSS option internally uses the unused area of the partition for updates/writes during the backup operation. So backing up this area with VSS in my opinion does not make much sense as you do not have control what data are contained on the backup in the unused blocks. I think the only use case for a "raw backup" is to make a snapshot before you try to repair an inconsistent file system or recover lost/accidently deleted data. Making a VSS however prevents you doing this because your data might be overridden. Perhaps you can explain a bit more why you want do a raw copy in your case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure, no problem; essentially I'm trying to setup hot, block level backups of around 10-20 windows machines, the backups of which are then replicated offsite via zfs send/recv to a remote location (if you're unfamiliar, zfs incremental replication works at the block level of the underlying storage). By taking a full, raw backup every day to the same file(I use snapshots to preserve history rather than individual files), I can ensure that only those blocks that have actually changed on disk need to be replicated over the wire.
Without a raw option, a simple file delete could possibly change the block layout of the entire backup file, even though very little was actually changed on disk, causing a deluge of "changes" to be replicated over the wire and consume all the available bandwidth.
Right now I'm using some cobbled together scripts involving vshadow.exe and cygwin dd, and it gets the job done, but it's a little fragile for my tastes.
I wasn't aware that shadow copies actually exposed the underlying unused blocks if it was using it internally to track changes; I would have hoped it would have returned zeros for those blocks, but in any case, the actual imaging I'm doing is fast enough, and during the off-hours, so currently the bandwidth to the remote site is more than enough to handle the changes we're seeing, even including any extra cruft that might be being replicated due to VSS change tracking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I'm trying to use your app to take continuously updated images of windows boot drives on a daily basis. For my use case an ideal backup would be a "raw", full disk copy taken off of a VSS snapshot, however enabling VSS seems to automatically enable the usedblocks feature. Would it be possible to enable snapshots without enabling the UsedBlocks feature, similar to the raw mode of driveimage xml?
That's an interesting question. I thought about offering this option but came to the conclusion that it doesn't make much sense. The VSS option internally uses the unused area of the partition for updates/writes during the backup operation. So backing up this area with VSS in my opinion does not make much sense as you do not have control what data are contained on the backup in the unused blocks. I think the only use case for a "raw backup" is to make a snapshot before you try to repair an inconsistent file system or recover lost/accidently deleted data. Making a VSS however prevents you doing this because your data might be overridden. Perhaps you can explain a bit more why you want do a raw copy in your case.
Sure, no problem; essentially I'm trying to setup hot, block level backups of around 10-20 windows machines, the backups of which are then replicated offsite via zfs send/recv to a remote location (if you're unfamiliar, zfs incremental replication works at the block level of the underlying storage). By taking a full, raw backup every day to the same file(I use snapshots to preserve history rather than individual files), I can ensure that only those blocks that have actually changed on disk need to be replicated over the wire.
Without a raw option, a simple file delete could possibly change the block layout of the entire backup file, even though very little was actually changed on disk, causing a deluge of "changes" to be replicated over the wire and consume all the available bandwidth.
Right now I'm using some cobbled together scripts involving vshadow.exe and cygwin dd, and it gets the job done, but it's a little fragile for my tastes.
I wasn't aware that shadow copies actually exposed the underlying unused blocks if it was using it internally to track changes; I would have hoped it would have returned zeros for those blocks, but in any case, the actual imaging I'm doing is fast enough, and during the off-hours, so currently the bandwidth to the remote site is more than enough to handle the changes we're seeing, even including any extra cruft that might be being replicated due to VSS change tracking.