L1 Community Colocation (Raspberry Pi's, Mini PC's, Virtual Machines, Data, etc)

Exactly, and there is nothing stopping us from having some kind of reputation system much like the sales subreddits on reddit have. If you’ve hosted 10 peoples backups for 10 years, clearly there is very low risk. Now if some guy joins with a Russian IP address and wants as much hardware sent to him as possible… Hmm, maybe he’s a little off and we use our judgment to not use him

Personally for me, I don’t care. I’ll rate limit you on a VLAN to not interfere with my work in the day, but if you wanted to push TB upon TB every night, I don’t care. I can also throw you on my second WAN, in which case you could max it out 24/7 for all I care unless I need to use it, in which case I just rate limit you. Very easy to setup limiters in pfsense

Also, I generally know how much data I’ll be transferring. So if I need to push down 2TB a night, a discussion can be had if that’s okay or not with the people involved

I wouldn’t give anyone a dedicated IP address, they could have a port number for SSH, and then the rest is up to them. I’d assume most people would just have their device VPN back, in which case you don’t even need an open port on my end

1 Like

I’m kinda interested in this concept as well, having the same problem of not really having tech-savvy friends who self-host things as much as I do. I’d probably tend more towards a software-only approach where no hardware exchanges hands, but we exchange IPs/hostnames and SSH pubkeys and transfer encrypted backup images across the internet. Disk quotas can ensure that size limits don’t get exceeded. I’m not really in a position to do this right now, as my ZFS NAS on my server is over 80% full and I don’t have enough free space for reciprocation of someone else’s data.

Linus Tech Tips explored this backup reciprocation concept in a sponsored Synology video a few years ago: Backing Up Your Life is THIS Easy - YouTube

2 Likes

I’d be interested in something like this myself. I do have 2 locations or potentially many more, across the globe that I can use by myself, the only problem with that is potential debugging across the globe via phone, in different time zones, without remote control, with non-tech savvy people. Trust me, I’ve done it and it ain’t pretty.

But there are a few problems with the colocation approach you propose mostly involving trust. But I’d be down for it on this forum.

Normally you cannot guarantee a few things:

  1. That the other party will not use the NAS as a VPN and use your connection to pirate stuff and get you in trouble.
  2. That the hardware you colocate will be well maintained, like on a UPS and in a room that doesn’t get a lot of heat or dust, or if it does get dusty, at least that it gets cleaned up from time to time.
  3. That the other party will not just steal your hardware, or allow you to use his connection a week or two, then ghost you.
  4. That you get the same in and out bandwidth, unless you agree not to dispute this too much.

Some of those issues can be fixed. For the purposes of this discussion, party A = you, party B = the other party. We could have each party set up their box to connect to a VPS via wireguard. Everything is plug and go, to make it as trustless as possible. Box B on network A is only allowed outgoing to the internet to the VPS, only on the wireguard port and nowhere else. Same for box A on network B. Both parties back their data through the VPS to their colocated boxes, only through the wireguard IPs.

This way, we insure that the home connection won’t be used for piracy. On the VPS, you don’t allow the IPs from the wireguard tunnel to access the internet either, they will be basically blind to the outer world. This insures that:

  1. The data cannot be exfiltrated even if the box is hacked by other parties, unless they gain access to the network A or B firewall as well.
  2. That one party does not misuse the network connection of the other party.

We still don’t get around the potential of the party stealing your hardware, but that risk should be assumed from the start anyway. You have to put trust in the people you are going to collaborate with anyway when it comes to colocation. Besides, you should expect your hardware to burn down and party B should expect the same to theirs. But the chances of both places burning down around the same time or in quick succession are close to 0. So you would both benefit from this security for backups.

One other thing. In the same country, it may be easy to ship stuff, but to other countries, it is not as easy and it’s also potentially more expensive due to tariffs and other stupid politics. So, easiest thing to do would be to make an account with a local shop there, use your own debit or credit card, or something like privacy . com and buy stuff in your name or pseudonym and ship them to party B. Party B can do the same to party A.

I’d be down for something like this, but I’m short on money, I’d like to get a nice backup location to someone’s house for some important files.

I would not really do it in the real sense as a colocation for backup services, like say, DR site where I would keep a replicated DB and HA servers. I would only use this option as a backup location.

2 Likes

Not at all. I have no emotions about this solution. :slight_smile:

I get the impression that you are a bit too personal and negative. :slight_smile:
I only have casual discussions and exchanges with you. I do not negate your concept, I only express loose perceptions… brainstorm… :slight_smile:

As I mentioned before, you are not the only one, I also had similar ideas and there is nothing wrong with them, :wink: which does not mean that sometimes someone cannot look at the matter from the side perspective and express his opinion. :wink:

So let’s focus on the specifics then…

How much bandwidth could you allocate per person? And the other party has to give exactly the same?
How much hardware are you ready to accept, just sbc or some rack server?

Instead of Pi, I would see Odroid HC1 / HC2 in this role, only that they are already EOL, unfortunately. :confused:
One sata disk, 1Gb eth… just right for such a project. :slight_smile: Or zeropi and larger sd cards instead of hdd. :wink:

What access to this sbc could a person have … the question is whether I can do what I want or whether it must be traffic limited to backups. How with public IP / NAT will you agree to p2p?

I have a lot of questions and please don’t take it negatively because no one is trying to deny your idea. But if you can’t even ask about such mundane matters, I see a lot of problem on the horizon.

After all, we need to explain some ABC scope and not just exchange equipment and… and what next? Since no aspects of the project can be established because you perceive other people’s discussions as something negative. :frowning:

I try to be as polite and friendly as possible … so don’t take it the wrong way because there’s no reason. :slight_smile:

About bandwidth concerns, I’m half way through my billing cycle

I wonder how much would cause concern

2 Likes

What about a simple storage swap over plain FTP, and allow the other person to decide how they want to allocate it? Pick a protocol that won’t grant shell access, or heck an S3 endpoint.

For example, say I want to store X TB offsite. Instead of buying the hardware and shipping it elsewhere, all you have to do is allocate that amount of storage locally for trade.

2 Likes

It all sounds like a good idea and in theory if everyone has great bandwidth you could sort-of make it work.

Partner up with someone who can offer you X GB of storage, via say ZFS and a VPN. You store my stuff, I store yours. We both encrypt a loopback filesystem and replicate via ZFS send snapshots.

However… where I can see it falling down is when I am for example wanting to download my 10 MB/GB/TB/whatever from your connection and you get the shits with my bandwidth consumption interfering with your life.

Unless there’s some sort of assurance that I’ll be able to recover my data if I lose it, the concept of backing my data up somewhere loses its viability.

which is why we establish a contract and payment for same.

I think where you might get some traction is sharing lab environment stuff. e.g., you give me VPN access to a VM lab in exchange for VM access to a PLex server or whatever.

Stuff that is temporary/not mission critical, etc.

Backups… no way I’ll trust those to someone I don’t have some sort of formal agreement/payment/contract with.

i would be cool with this though id put peoples hardware on a dedicated router that puts all there data through some compute instance on a cloud so it wouldnt be my own ip. proabably make sure to have a speed cap of like 50/50.

Establish cooperation with…

Just got around to reading this thread.

I like the concept, but I think this would turn into a dumpster fire almost immediately once any significant number of people became involved.

I think it would be possible to keep under control but probably with more management than anyone would want to put in… this is kinda what I imagine:

  • Someone close to L1 would make an ‘official’ host image/container/whatever you want to call it. Probably just some Linux with configuration already done. Implement all of the networking/containerization infrastructure people could reasonably want, rate limiting, and maybe some form of CRC/integrity check.

  • Maintain a community page of people who are hosting or have space available - keep it standardized, have fields like # of machines available, machine type/specifications, maximum network rate, ‘lease’ time, etc.

Anyone that wants to host could grab a copy of the L1 Remote Services Image™ and put an entry up on the community page. A wiki would work well. Anyone that wants to use one could get contact info from that page.


I think that would work well, but it would need a lot more coordination and management than I think anyone on the L1T admin crew would be interested in taking on.

1 Like

The only way this would work imho would be to ensure multiple replicas.

I.e. distributed content across multiple third parties. So if one goes down you still have access to your stuff

1 Like

For this, I suggested a private tracker and torrent based spread. :wink:

100% workable imho.

Access to the tracker for a selected group of people l/p + 2fa and all based on ssl. Of course, the data is individually encrypted per client so that no one else will be able to look inside what is hosted / sent.

Anyone has the right to add a new item on the tracker, provided that he is doing a seed for the remaining content.

A way to create a backup according to the user’s preferences. At your discretion, the size of the file, its segmentation, type of software, type of encryption.

You want one large veracrypt container file… No problem.
You want lots of rar files… no problem.

You create a torrent file for your content which may be in any form the user prefers.

With a group of, say, 10-20 people, it would start to make sense. Greater availability of source hosts. For the downloader of his data more guarantee of optimal download speed.

Security and confidentiality of data ensured by the chosen method of encryption at your discretion.

If we want to go in the direction of paranoia, this p2p movement can always be wrapped in something like tailscale / zerotier.

Hosting a torrent tracker doesn’t require a lot of resources, neither space nor processing capacity. This causes the space to be hosted to increase without the need for large maintenance investments.

You can host it with someone or buy some cheap resources from one of the dedi / vps / cloud providers. Even L1 could become the official host, on Linode or in @wendell basement. :slight_smile:

Of course, we are talking about backups that are encrypted and do not have any indications of their contents. By definition, only legal things to which a person is entitled. Of course, since the content is encrypted and no one will confess what is backed up, it is more of a conventional well-being issue.

1 Like

Totally up for that!

Just throttle it. Easy in PFSENSE and most other setups. Personally though I wouldn’t care

Have you ever read those contracts? Most cloud storage providers could just ditch your data with no notice and no penalty.

Note that this is a backup, and an off-site backup at that. Personally I only keep 5 days of retention in the cloud. If that 5 days went missing, I don’t even care

Sounds good to me also

Pretty easy to do with most VPN providers also, I’m using mullvad and doing just what you described

All traffic goes in and out for some things all via mullvad

A few people here seem to be getting confused with what this would be used for, this is not primary storage, this is backups

As part of a 3-2-1 backups strategy, this idea works great. Its not your only backup so if it vanishes out of the blue, its not critical

If anything goes down and causes an impact to you, then you don’t have backups. My main NAS, secondary NAS, on-site backups, cloud backups and off-site backups could each fail on their own, and I wouldn’t even be concerned

What if we replaced sending sbc/pc to micro sd cards? And host them through your own hardware… You don’t need a lot of resources because, as you say, it’s supposed to be the final, least important backup. Send a micro sd no problem, or send $ for a second person to purchase locally. For this some hub / usb reader and a bit of resources on the server. :wink:

As mentioned before, people may be reluctant to submit sbc / pc for a number of reasons. :confused:

I’m also absolutely serious about this p2p or talk to @wendell , you have the perfect condition for an exchange. :slight_smile:

So the SD card itself would be the storage? The issue there with me personally is that I have no good way of getting SD cards into an ESXi server

May as well just send me a .img of the SD card and I can mount it in a VM

1 Like

More or less it would be like that. :wink:

In that case, you would have to run some small virtual machine on your esxi to take care of the resources. And just pass sd to vm like any other usb device. If, on the other hand, the machine does not have the ability to lead one usb port outside to some hub where there would be sd, it is actually a problem. :slight_smile:

So, in effect, we come to the beginning of the debate cycle. :slight_smile:
Just share xyz capacity on your server and get the same from another person without having to physically replace the hardware between the parties. :slight_smile:

I generally do not say no, but currently the prices for sbc do not encourage such a solution. :slight_smile: But in the future…

And I mentioned @wendell because he is potentially the second person after @judahnator who has a server back-end ready and may be interested in another location for backups. :slight_smile:

1 Like

I think the best way to do this is using TrueNAS Scale since it builds its multi node storage clusters with the GlusterFS (at least this will be the easiest). The problem with is if you have one person with a slow WAN link, machine, etc. It can impact the whole cluster if you are not careful. The cool part of this is you can get the number of replicas under solid control and de-dup a bunch of stuff that people have which are the same.

1 Like