We used a couple of alternatives after LogMeIn bought Hamachi and retargeted it at enterprise users, but none of them were ever quite as good. And as games have continued to strip out LAN support and/or gotten better at working through NATs, it's been a while since I needed anything like it.
No longer using Bvckup (my photo library doesn't live on my Windows machine anymore) but it was a nice change of pace to run something where it felt like the developer actually thought about the interface. With most utilities on Windows that's really not the case.
I do think however that extracting its p2p tunneling bit into a separate service could be a good thing to do even now. Its NAT punching was server-driven, which was (and still is!) a superior way to do it. Better timing, tighter port prediction. Heck, it could even establish _TCP_ tunnels through the simultaneous open trick.
In addition to the LAN gaming over the Internet, the second best thing was pranking people by printing random stuff on their LAN printers.
I didn't end up deploying it because for Hyper-V, performance of the differential scans was really poor, and IIRC there were some issues with cluster shared volumes.
Have you considered adding Windows' resilient change tracking support to bvckup2? I think with RCT and hooking into the API for backup quiescence, you could make this an enterprise grade backup product for SOHO IT needs.
Do you remember the details? First time I hear of something like this.
Re: RCT - I read up on it a while back and the overall impression I got was that it was an application-level re-implementation of NTFS write change journaling. So filed it under 'exotics' and moved on.
Skimmed through the specs again now and I think that it's a good feature to have. Basically, RCT gives the program a change list for a VD for free IF it knows how to retrieve it. I made a note, will see what I can do. Thanks for the nudge.
RCT not only gives the change list, but I believe it also ensures that on a cluster shared volume (CSV) there is an easy way to safely get the changed blocks. Normally a VSS operation on a cluster shared volume puts the drive into redirected mode, in which all IO has to go through the host that owns the CSV at that time. That also negatively affects performance, effectively limiting throughput to whatever the network speed is instead of the usually much faster SAS bus.
Re: full scan issues - that's likely due to bvckup2 being too aggressive with the IO. This is something that's easy to change [1], though I realize it's not a very good excuse and it should not require manual tweaking to begin with.
Thanks for making Bvckup, its one of those tools I never knew I needed till I got it.
If my destination doesnt actually have a copy of the data, but only the metadata (onedrive sync with filespace freed up, nasuni with files purged from the cache) can bvckup write only the changed blocks, or for example, would the nasuni need to pull the file from the cloud master back into the cache before it can patch it with the delta? Maybe this is such a tech specific question it doesnt have an answer.
Block hashes are computed either when the file is first copied to destination (by bvckup2) OR when the exact copy already exists at destination and the backup job is set to do "delta pre-comp" [1].
If in your case the latter applies, you may in fact get away with setting up delta copying without pulling any data off the cloud storage.
If you get an EV cert, it gives you an instant pass through Microsoft's SmartScreen, meaning that the warning the Edge (or what it's called bow) shows upon downloading is less scary.
It looks nice and straight forward, so I give you your props for that.
In terms of dependencies - just the Windows API and a bit of Native API, if available. No WMI, very little of COM (for shell and shadow copying). It does however use quite a few exotics from the Windows API, e.g. SetFileIoOverlappedRange, SetFileCompletionNotificationModes, etc.
Or something else?
From what I've seen NTFS is a really well-made file system. There is indeed a fixed per-file overhead that becomes an issue when working through lots of small files, but NTFS handles multi-threaded access very efficiently, so that's a very easy workaround.
I thought I'd do a Show HN for two reasons.
1. I obviously want to show my baby to those who haven't seen it.
Its primary purpose is to do very fast file replication. If you are familiar with "robocopy /mir" - same idea, but on steroids. Lots of them. It can be used for both mirroring and archiving backups, among other things.
It is light, very small and it is really quite fast. Half of the development time was sunk into the UI/UX design, so there's that too.
Existing version is a result of 5 years of a _very_ careful evolution, focusing more on perfecting existing features rather than adding new ones. Said No to more feature requests than I can remember. The blog captures some of that in a form of development screenshots, sketches and what not [1].
2. Secondly, I wanted to add an anecdotal data point that the desktop software development is still very much an option despite of all the nasty rumors. The demand for well-written Windows software is still there. The biggest takeaway has been that there is LOTS of people, on Windows, that recognize software quality as a feature. They acknowledge and compliment it, and they are actively looking for it.
That's the niche. If you are thinking of trying the Windows ISV path, I'd aim there.
By the way of introduction - I'm in my mid 40s. I've been a programmer for my entire life, mostly on the sysdev side of things - firewalls, network stacks, VPNs, etc. - which is one of the reasons I still like things to be as small and as fast as possible. I'm also the original author of Hamachi VPN, there's a chance you might've heard of it.Any thoughts or comments on the program itself, would appreciate to hear them. If anyone has any questions, I'd be happy to answer them if I can as well.
[1] https://bvckup2.com/wip