Update snapshot

[Dougal]

The snapshot feature is great, but I was wondering if it is possible to update a snapshot without rebuilding a complete new one?
I have created snapshots of the several data sets I have, and then use them to compare and find differences. Once I find a difference, I investigate to work out which is correct, then delete or copy as required to update the incorrect location. I would then like to be able to just update that record in the snapshot, without having to scan the complete dataset to create a whole new snapshot. I am thinking something like load the snapshot and stop the comparison, then drill down in the folder tree to where the change was done and use the copy to replace the data in the snapshot with the data from the updated file/folder. Is this already possible? Snapshots seem to be read only.
I often seem to have to touch a single file out of millions, and would be much quicker to update one entry that recreate the full snapshot if possible.
I have to say this is a great program regardless of this feature, it has saved me an incredible amount of work, and allowed me to verify several large data stores we have. I am yet to use the remote update (sneaker net) feature, but that also is going to be a godsend.
Cheers

[Aaron]

Hello,

Snapshots do not support any editing in the current version of BC3. Adding the ability to update a snapshot file is on our Customer Wishlist, but is not likely something we would be able to add soon.

Just in case you (or another user) has not stumbled upon it yet, here is our "sneakernet" KB article:
http://www.scootersoftware.com/suppo...=kb_sneakernet

[Dougal]

Thanks, that looks like just just what I needed. I guess I should RTFM. I haven't used it yet, have to wait to sort out licenses. We have a conference coming up soon, I plan to push for a group license from our boss if I can get enough enthusiasm for it (which I don't think will be hard).
I just created a complete snapshot (filenames and dates) and took about 3 hours, so isn't impossible to re-create, especially as once I get the various data sets in sync, there will only be occasional changes. Obviously if I add CRC it is going to blow out a lot, and may not be possible. I am currently using the snapshot for comparison to identify any different date files, then using direct comparison to determine if they really are different or not. As they are mostly static data that seems to work fine.
Cheers

[ron]

Well, this post answered my question. There might be other tools to accomplish what I want, but the snapshot feature seemed ideal - except that I can't "update" it.

Recently I encountered a rare BSOD on Win 7 - rare for me. A few days later I went to run a program I use allot. It failed to run. Come to find out one of its DLL's was zero bytes. Then I recalled that I suspected the BSOD came about during the nightly backup. Glad weeks/months didn't lapse before I caught that. Imagine an even worse scenario where "data" got changed when you didn't expect it. If enough time passed before you realized the data was gone, a backup might be of no use.

So I thought I'd monitor key files that seldom ever change. Data is going to take further thought. After all, by its nature it can change allot. So you really only care about the data that seldom or never changes.

I don't know what the structure of the snapshot file is like, but if I could just take the view I have now and have the changes on the opposite side re-analyzed and applied to the snapshot, that would be ideal.

[Aaron]

Thanks for the feedback, ron. The BSOD and DLL issue: was that due to copying "to" a live location, and it copied a 0 size file, which caused that location to be unstable?

Would rebuilding a snapshot (of size/timestamp) be sufficient, or do you need CRC checking for other cases?

[ron]

I'm not sure. It doesn't make sense that during a backup the source file would ever go to zero bytes. Unless with lotto odds the O/S crashing at the very moment of the file open caused it to loose info in the allocation table about the file. Of course the file was likely in-use with the program running. So then you've got to consider all the things that could go wrong if the BSOD occurred during the shadow copy.

In my life this has only happened twice and I totally do not remember the circumstances for the other one.

To account for lotto odds like above, you'd need to update the CRC too. Considering that would take very little time for the assumed small number of changes one would expect to occur after the initial scan. In that way you're assured that no data is lost - to the degree that CRC can assure you.

I once came across a defective thumb drive from Patriot. I could copy a dozen jpegs to it and turn around to compare what I copied with the source only to find very interesting visual differences. Huge chunks of 2-4 of the jpegs would be missing. The sizes were identical, but not the contents. They sent a replacement, no more problems.

Photos are a good example of data you might not look at for a long time and are seldom changed. So if the file contents got changed somehow, that's a red flag and something I'd want to know about. Over the years I've accumulated quite a bit of valuable and irreplaceable data. I keep three backups - one off site - but they get recycled about every 90 days. So if some data goes bad, I'll likely never know because most of it is never accessed for years.

Around '92 a friend of mine had a hard drive that acted like the thumb drive I described above. Data being changed when it shouldn't have been. Back when controllers were add-on cards

I thought a tool might already exists but a quick Google search didn't turn up anything. It's kind of geeky, but so were backups 15 years ago.

I'm thinking of writing something myself but have not been able to find the time. Think of it like a seal, where you could seal a file with a (CRC like) signature. Then every so often have those seals verified.

In the 90's Norton did this before virus signatures became vogue. It basically sealed "important" files and would let you know if they changed.

[Aaron]

Hello,

BC3 should definitely not 0 the source file in a copy; this would likely be caused by general system instability or the BSOD mid-crash.

Do you have CRC (or Binary) content scanning enabled in the Session Settings? This would content scan your entire folder and does compare the file pair on load or after a copy.

[ron]

I think you're not interpreting my post correctly. BC3 was not in use when the 0 byte file came to be. But if snapshots could be easily "updated" as the original poster suggested, BC3 could be used to easily and quickly alert me to such a condition.

[Chris]

Ron,

Thanks for the clarification. Updating snapshots, including update of CRC values is on our wish list for a future version of BC.

[kenlohwh]

I agree with the other users in this thread that the ability to update a snapshot is an important feature. Building an entire snapshot just take too much time that it disallows incremental rapid changing of a file system.

[Aaron]

Thanks. This is something still on our wishlist, but not something we've been able to tackle.