OP Currently has in their possession 2 drives.

OP has confirmed they’re 12TB each, and in total there is 19TB of data across the two drives.

Assuming there is only one partition, each one might look something like this:

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 12345678-9abc-def0-1234-56789abcdef0

Device         Start        End            Sectors        Size      Type
/dev/sda1      2048         23437499966    23437497919    12.0T     Linux filesystem

OP wants to buy a new drive (also 12TB) and make a RAID5 array without losing existing data. Kind of madness, but it is achievable. OP buys a new drive, and set it up as such:

Device         Start        End            Sectors        Size      Type
/dev/sdc1      2048         3906252047     3906250000     2.0T      Linux RAID

Unallocated space:
3906252048      23437500000   19531247953    10.0T

Then, OP must shrink the existing partition to something smaller, say 10TB for example, and then make use of the rest of the space as part of their RAID5 :

Device         Start        End            Sectors        Size      Type
/dev/sda1      2048         19531250000    19531247953    10.0T     Linux filesystem
/dev/sda2      19531250001  23437499999    3906250000     2.0T      Linux RAID

Now with the 3x 2TB partitions, they can create their RAID5 initially:

sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sda2 /dev/sdb2 /dev/sdc1

Make ext4 partition on md0, copy 4TB of data (2TB from sda1 and 2TB from sdb1) into it, verify RAID5 working properly. Once OP is happy with the data on md0, they can delete the copied data from sda1 and sdb1, shrink the filesystem there (resize2fs), expand sda2 and sdb2, expand the sdc1, and resize the raid (mdadm --grow ...)

Rinse and repeat, at the end of the process, they’d end up having all their data in the newly created md0, which is a RAID5 volume spanning across all three disks.

Hope this is clear enough and that there is no more disconnect.

deleted by creator

Fun story but I’m most impressed with the earbud part of the story. WOW. Absolutely amazing and unexpected.

This is smart! Should help reduce the number of loops they’d need to go through and could reduce the stress on the older drives.

I’m afraid I don’t have an answer for that.

It is heavily dependent on drive speed and number of times you’d need to repeat. Each time you copy data into the RAID, the array would need to write the data plus figuring out the parity data; then, when you expand the array, the array would need to be rebuilt, which takes more time again.

My only tangentially relatable experience with something similar scale is with raid expansion for my RAID6 (so two parity here compared to one on yours) from 5x8TB using 20 out of 24TB to 8x8TB. These are shucked white label WD red equivalents, so 5k RPM 256Mb cache SATA drives. Since it was a direct expansion, I didn’t need to do multiple passes of shrinking and expanding etc., but the expansion itself I think took my server a couple of days to rebuild.

Someone else mentioned you could potentially move some data into the third drive and start with a larger initial chunk… I think that could help reduce the number of passes you’d need to do as well, may be worth considering.

They’re going for RAID5, not 6, so with the third drive these’s no additional requirement.

Say for example if they have 2x 12T drive with 10T used each (they mentioned they’ve got 20T of data currently). They can acquire a 3rd 12T drive, create a RAID5 volume with 3x 1TB, thereby giving them 2TB of space on the RAID volume. They can then copy 2TB of data into the RAID volume, 1TB from each of the existing, verify the copy worked as intended, delete from outside, shrink FS outside on each of the drives by 1TB, add the newly available 1TB into the RAID, rebuild the array, and rinse and repeat.

At the very end, there’d be no data left outside and the RAID volume can be expanded to the full capacity available… assuming the older drives don’t fail during this high stress maneuver.

Even if you could free up only 1GB on each of the drives, you could start the process with a RAID5 of 1GB per disk, migrate two TB of data into it, free up the 2GB in the old disks, to expand the RAID and rinse and repeat. It will take a very long time, and run a lot of risk due to increased stress on the old drives, but it is certainly something that’s theoretically achievable.

Pretty sure UniFi Access can also control the lock mechanism they’re describing. So it’d be a nicely integrated solution.

You aren’t wrong, but that’s also the point… It makes no difference if they’re securing a VPS or their own network. In fact, they’d need to secure both systems — and I’ve seen so many neglected VPS’s in my time… I’ll be the first to admit: myself included.

There are very valid reasons to need a tunnel; CGNAT, ISP level port blocking, network policies (ie campus dorm), etc etc etc. However, if you read the other replies, this doesn’t seem to be the case here, and OP doesn’t seem to even know why they’re hiding their IP. They just wanted to do it because of some loose notion that it may be nice since they’re opening up their port.

For someone in that situation, introducing a whole stack that punches through the firewall via an VPN or alike introduces way more risk than just securing down the gateway directly, and handle the other issues as they come up.

Say someone wants to take your service down, you’ve got 500Mbits line at home ISP, and 10Gbits on your VPS; they sends 1Gbits of traffic to your VPS, your VPS happily tries to forward 1Gbits, fully saturating your home ISP line. Now you’re knocked offline.

Say someone discovers the actual IP, dropping traffic from anything else other than the VPS doesn’t help if they just, again, flood your line with 500Mbits of traffic. The traffic still flows from the ISP to your gateway before they could be dropped.

Say someone wants to perform SQL injection on your website, there is no WAF in this stack to prevent that.

Say someone abuses a remote code execution bug from the application you’re hosting in order to create a reverse shell to get into your system, this complex stack introduced doesn’t protect that.

You’ve provided a comprehensive guide, and I don’t want to single you out for being helpful, but I must ask: What problem does this solve, and does OP actually have the problem this stack can solve? From the replies we’ve seen in this thread, OP doesn’t have sufficient understanding to the full scope of the situation. Prescribing a well intended solution might be helpful, but it gives a false sense of security that doesn’t really help with the full picture.

You do not strictly need to open a port – tunnelling through another server could be a solution, but let’s park this for a moment.

What you are describing as “open a port in my firewall” is actually many smaller parts, some key ones that may be relevant are:

1. (Firewall) Telling your gateway to not drop traffic when someone outside is request to connect to the specified port; and
2. (Port Forwarding) Telling your gateway to forward traffic from that port to a specific computer’s specific port within the network (i.e.: your computer, port 80)
3. (Running a service) Having a service (say for example, a web server) running on the specified computer’s specific port answering requests

All three things (amongst others that’s not immediately relevant here) must be properly setup for any network request to happen. What do I mean by that? I can have a port not drop traffic (i.e.: firewall down). When someone from outside of my network trying to access the port, they’d get to my router, but nothing happens because there’s no where for the packet to go. I can have my firewall down, and port forwarding enabled, but the web server isn’t running. When someone from outside of my network trying to access the port, they’d get to my router, get forwarded to my computer, but because the web server isn’t running, nothing happens. Someone from outside of my network can only gain access to my service (and only that service) only when all three are setup and working together.

“But what about the hackers?”

Yes, the untrusted networks, such as the internet, could be a bad place with people with bad intentions. There are many different things they could do to make things undesirable; let’s explore some of them together.

Say we want to run an instance of Lemmy using a new experimental server software (i.e.: not the official Lemmy server). Now, unfortunately, some racist people decided to come and make racist posts on our instance. A tunnel / proxy doesn’t solve this. Instead, we have to ban their accounts. It may not seem much, and it was completely innocuous to our system, but we’ve just dealt with our first attack.

One of those racist person happens to be the “scary hacker” type, so they came back and try to brute force our admin account’s password to unban themselves. This is not too bad, but we need to address this somehow. A tunnel / proxy doesn’t solve this; but something like Fail2Ban might be able to look at the login failures and put a temporary IP ban on the attacker.

They’re back! And this time, they decide to repeatedly hammer the search function, thereby taking all the resources from our database, so our instance cannot serve other users. A tunnel / proxy doesn’t solve this; but some rate limiting configurations in the server application might help.

They’re not happy about getting rate limited there. So this time, they decided to continuously post garbage to our instance, not even normal requests, just connect to our web server, and spam AAAAAAAAAAAAAA… non stop, at such a quick pace that it fully saturates our network connection, and we cannot do anything else on the network. A tunnel / proxy doesn’t solve this; we’d need to block them from the firewall. This is not entirely true; blocking them at the firewall doesn’t solve the problem, because the traffic still goes from the ISP to the firewall, which will still be saturated before the firewall could drop the traffic, but to use as an example it narrates a potential problem well enough.

They’re angry now, and they pay a few bucks to botnets to have many many many thousands of infected computers to spam AAAAAAAAA… non stop at our service. Again, a tunnel / proxy doesn’t solve this; we’d need to have something smarter than just our firewall and individually ban the IP addresses. This is where we’d need the professionals with typically commercial offerings.

It could escalade the other direction. Instead of attacking with aim to take the service down, they could do other damaging things. Say they found a problem with our server software. Instead of giving the /post/<postid> a numeric id, they can do something fancy like /post/1 AND 1 ==1; UPDATE users SET banned = FALSE WHERE username = 'racist-user' and unban themselves. A tunnel / proxy doesn’t solve this; but a Web Application Firewall (WAF) might.

Now it escalades more. Through a complex chain of intentionally malformed image uploaded to the instance, the image resizer attempting to resize the image, which gets tripped over by the malicious image, which causes a remote code execution, which they use to create a remote access trojan (RAT) shell so they can connect to our server and run commands. This is usually the “big bad” that most people are scared of… someone from outside of their network having access to their system and thus gains the ability to extract their documents or encrypt their photos etc. A tunnel / proxy doesn’t solve this; but a WAF or an anti-virus on the server itself might.

Through these albeit simplified but lengthy exploration, we see that none of these would actually be addressed by a tunnel / proxy. There are other possible attacks, and they’d require other solutions.

So, goes back to what I was saying earlier… it is important to know why you’re trying to do something. Blindly prescribing tunnel / proxy doesn’t actually solve the problem.

What kind of attacks, against what service?

DDoS? It’s cheaper to hire botnets to attack than to defend. You’d most likely still be knocked off even just by the amount of traffic that leaks through your proxy before the VM gets cut off at the data centre. Specifically: it is much more likely that data centres will give higher thresholds before null routing your VM than your residential ISP would be wiling to tolerate.

Brute force on shell? SQL injection? Remote shell execution? Deploying the extra layer will not protect you from these as your own proxy will not give you WAF.

It is always important to know why you’re doing something, before anyone can prescribe a solution.

Again, that’s what you’d like to achieve, but why?

Without the reason, there is no way to provide a useful answer that would adequately address the underlying reason.

What is your objective for ‘hide server IP’?

Privacy to disconnect your identity from the service? There is no solution to this. Full stop. Even with Tor, the state backed acronym entities will figure it out if you get on their radar.

If your objective is to keep your service online, you’re going to be hard pressed to find cost effective alternatives… Commercial solutions are expensive, like, “if you have to ask about the price, you can’t afford it” expensive.

Alternatively, you can try to roll your own by having many many proxy servers yourself… but if you’ve got a target on your back, you’ll never have enough instances; DDOS-as-a-Service is much cheaper than the amount of reverse proxies required to keep your service online.

There’s probably other use cases, but chances are, you’d still be hard pressed to find a solution that’s cost effective.

Locks can happen by registrar (I.e.: ninjala, cloudflare, namecheap etc.) or registry (I.e.: gen.xyz, identity digital, verisign, etc.).

Typically, registry locks cannot be resolved through your registrar, and the registrant may need to work with the registry to see about resolving the problem. This could be complicated with Whois privacy as you may not be considered the registrant of the domain.

In all cases, most registries do not take domain suspensions lightly, and generally tend to lock only on legal issues. Check your Whois record’s EPP status codes to get hints as to what may be happening.

My understanding is that the “host” instance of the community is responsible in sending things out to the subscribers. As such, when users from B post on a community on C, C will broadcast the activity of user from B to instance A’s federated copy of community on C, and users on A will see the post from the user from B. They should also be able reply to each other’s comments on the community on C.

So just because they don’t know technology like you do, they should be left behind the times instead of taking advantage of advancements? A bit elitist and gate keeping there, don’t you think?

Everyone have their own choices to make, and for most, they’ve already decided they’d rather benefit from advancements than care about what you care about.

And here’s the reason why layman should not: they’re much more likely to make that one wrong move and suffer irrecoverable data loss than some faceless corporation selling their data.

At the end of the day, those of us who are technical enough will take the risk and learn, but for vast majority of the people, it is and will continue to remain as a non starter for the foreseeable future.

The amount of people who would pay is going to be near zero in the grand scheme of things.

Next time you’re anywhere where you could discretely look at people’s phones, see how many of them run apps with ads. Most apps will offer very cheap IAP to remove ads, but people choose to not pay it. Vast majority of the users have already decided that their time wasted on ads are worth less than whatever tiny monetary cost it would be to remove them. Same thing here: Vast majority of the users have already decided they’re not going to pay to get rid of the ads. This in turn means due to how few people who would be willing to pay, it is not going to be nearly sufficient to keep the infrastructure required up and running, as well as keep the creators compensated for creating the content.

Japan has nicovideo.jp as well. Russia has Yandex Efir (gone through a couple rebrands, Efir was the name in 2020 when we were discussing deals; it was operating under another name prior, and I think it is superseded by dzen). Off to the side I think vK also has a small video delivery presence like how Facebook has videos in their feeds. China has several platforms: Tencent Video (owned by Tencent), Youku as you’ve called out (owned by Alibaba), XiGua (ByteDance), Haokan (Baidu), and then slew of smaller ones like KuaiShou, BiliBili and that video thing WeChat tries to push. None of these are public service operated by the State, by the way. List really goes on… and I’d know, because I’ve worked in the space for almost 12 years now.

China’s great firewall aside, all these platforms are tiny in comparison, and in the grand scheme of things, and barely have any reach. In general, these regional are all taking a backseat just like Nebula and alike — if creators’ content are hyperlocal/super niche, they might be okay with smaller regional platforms; but if they’re trying to extend their reach and monetization (to ensure they have money to continue producing content), the creators’ presence on these platforms are really just auxiliary to their primary presence on YouTube.

Getting viewers to these smaller platforms is going to pose a significant chicken or the egg problem — creators aren’t incentivized to be there because lack of viewer, viewers aren’t incentivized to go there because lack of content. Worse yet, I’ve also seen situations where creators are paid for some period of exclusivity and then when the deal lapses they just go straight back to YouTube.

Real competitors do not exist, and likely will not exist for the foreseeable future. YouTube is the million pound behemoth when everyone else barely registers on the radar.