I know about those. Since the whole point of innernet is making wireguard configuration simpler, I figured maybe integrating something like that is worth doing.
I feel that adding TCP support would push innernet beyond a WireGuard configuration manager and into something a bit more behemoth. I'm quite fond of the fact that innernet doesn't "touch the packets" in its current state.
That said, if a strong need arises over time it's not out of the question, and in the mean time anybody is welcome to add their own wrapper around innernet or fork it to support that.
At vultr you have the option to "bring your own ip", as they call it. This really just allows you to use BGP to announce whatever prefixes you own. You could have a /40 behind each of your servers if you wanted to.
Which is great to have as an option--but otherwise, it's a stupid idea. The whole point of having such a large address space with IPv6 is to enable aggregation of routes. So, every vultr datacenter should have at most one route in the global IPv6 routing table, for a huge prefix that all their customers are aggregated under. Having customers announce their own provider independent address space might well have its legitimate uses, but it adds additional routing table entries to the global routing table, which is why it's a terrible idea to do this instead of just assigning customers /48s from their provider aggregated space.
If you are running postfix as your mail server, you could use something like [0] (or write your own solution, utilizing a database or whatever, of course).
I think one of the problems I'm having is figuring out where the product would fit in my workflow.
Are you looking for people with dedicated backup and recovery?
Are you looking for people without BaR but uses a lot of VMs?
Should I backup anything with this, or just my VMs and DBs? If so, how does it compare to [existing VM or DB backup system]
How does it compare to using rsync with hpn-ssh? Using hpn-ssh significantly improves rsync speeds, though I don't know how it works with sparse files since I use dedicated SAN backups for my VMs.
Tahoe-LAFS is a secure storage system (protocol and free software implementation). It does not handle synchronization between devices (only RAID-like replication).
AeroFS is a sync service (proprietary software only). It does not provide any storage, but only syncs data between your devices.
I'd use zfs (consider freenas as your os, i like it) with raid-z3 (triple-parity, thus 3 drives may fail w/o data loss) on the remaining 7 drives.
You then may use zfs snapshots + replication to the other machine or just use a cron job to wol the backup machine and simply run rsync at a certain interval.
The zfs question is one I'm debating. I actually already use FreeNAS on the backup server and it seems to be doing well. For the primary server I want an OS I can do more with on, so I'd probably throw something like CentOS on it and then run VMs for specific tasks or to use more bleeding edge distributions. I suppose I could try zfs in Linux.
[0] https://datatracker.ietf.org/doc/html/rfc6347