Good day!! My question is the following if I keep a daily backup of the data that I have in my hd and one day that hd dies and I replace it with a new one and I charge the last backup I had was disqualified? or nothing happens even if you don’t have the last files that were uploaded
Backups don’t really work. Since you’ll be missing files between the last backup and moment of failure. Chances are your node will get disqualified anyway. If you want some protection, then mirroring with RAID is the only way to do that. However, I would argue you should probably just not backup and run another node on the other HDD and make a little more money in the progress. In that case you can afford losing one of the two nodes as it was making you extra money to begin with.
A raid according to storj is inadvisable, so there is no way to be protected from disqualification.
It’s inadvisable for the reason I mentioned, you’d be wasting half your disk space that could also be making money. Backups would be inadvisable for the exact same reason, with the addition that it would also not at all ensure that your node will survive, so it’s even worse.
Well, the issue of disqualification I do not see just because after several years of collaborating with the first inconvenience you have with the hardware you are eliminated and I do not know if it is possible to obtain a new identity and in that case that all this entails
It’s very easy to get a new identity. That should not be an issue. If you request a token you get it almost immediately now. You’d be starting over and have lost the held back amount, but that’s just the price of losing data. And if you were running 2 nodes on 2 separate disks, it would only impact one of them. This is why neither RAID or backups are advised. Just give all the space to the network and maximize the profit.
Backups are pointless and restoring a backup would result in your node being disqualified for missing files between the last backup and the time of failure. I don’t lik this, but making it possible to restore a backup would probably require too much work to be done on the satellite side and presumably Storj does not think it is necessary.
On the other hand, RAID, in my opinion, is pretty much required if you want the node to survive a long time. Hard drives get bad sectors or fail completely frequently enough to require this.
Yes, in theory you could make more money buy running a second node on the drive that would otherwise be used for parity or mirror, however, that only applies if you manage to fill your array and assumes that both drives would work without problems.
If you are disqualified, a lot of bad things happen:
- You lose the escrow money.
- The new node has to go through the vetting process, meaning you get almost no traffic for at least a month.
- The escrow percentage is back at the high value
- You lose the data and traffic you already had and need to accumulate it from empty, that may take a while, even after the vetting is completed.
Because of the uptime and data integrity requirements as stated, I would strongly recommend using RAID. I would also recommend backups, but the design of the network is such that it is not possible to have backups, you can only do synchronous replication, which is what RAID is.
OK thank you very much!! I think I’ll think back to storj.
Well, it’s a long way from “the first inconvenience with hardware” and actually losing data.
On modern HDD’s there is a less than 2% chance each year.
I’d say if you have 8TB or larger drives, maybe RAID makes a little sense… but still, you’ll feel stupid when that fills up and both drives are still alive. From that point on you’re losing money.
And I’ll say this again. RAID is by no means required and in most cases not even recommended. I’ll keep repeating this, because I’m fine with admitting that there are cases in which RAID setups would be the better option, but you keep making it seem like it’s required for eveyone, which it is absolutely not. It is in fact nod advisable in most situations.
If I really care about that and want to risk it I can always pull one drive out and run a second node on it.
This is where, in my opinion, the recommendations and requirements contradict each other.
The recommendations say “run a node on a single drive on desktop hardware or a RPi”.
However, the requirements are pretty strict and require very good uptime and permit almost no data loss and also do not allow backups. That, to me, looks like requirements for a data center with RAID being mandatory if I do not want a few bad sectors to DQ my node.
(It is also not what I expect from recommendations, but I guess that’s my personal thing).
Still, recommending a simple setup while at the same time requiring datacenter-level reliability is setting those who follow the recommendations up for failure. However, failure not only results in lost escrow (which, I guess, is understandable), but also a few months with less traffic than normal, one month due to vetting and then you have to wait for the node to fill up again, which may take a long time.
I think we can agree to disagree and both propose our reasons to the new SNOs and let them decide which option thy want.
Keep in mind that those ToS are currently being rewritten. The uptime requirement is not in effect. You know I agree that the requirements as currently written are too strict. In my opinion the ToS should read less like a contract in which you promise to deliver a certain service and more like a set of rules and consequences. Disqualification of a single node is not the end of the world and shouldn’t be anything close to a breach of contract. It’s just part of the game, especially if you’re running multiple nodes. The ToS should reflect it as such. It currently does not.
Well, if and when the ToS get changed and the requirements are less strict, I may change my opinion, but right now I only have the currently available requirements to base my decisions on. As for the uptime requirement, AFAIK, it’s not in effect right now because Storj does not have a good way to measure the uptime, so, I would expect the requirement to be back as soon as Storj fixes the detection.
It does not matter (at least to me) if the ToS is written like a contract or a list of rules, getting disqualified means a month with pretty much zero traffic and then possibly many months with little traffic.
I’m wondering if one of the reasons they don’t currently enforce uptime is because it would result in too many nodes getting DQ due to the level of strictness. On the other hand, not enforcing uptime at all must be working if they continue to operate in this manner. Perhaps they will settle on a middle ground.
That is possible, though IIRC the official reason is that the detection does not work correctly and may DQ some nodes with les than 5 hours of downtime.
Or you could’ve kept that drive somewhere safe, not running, not aging. Or store something else on it.
And then the node drive fails and I wait multiple months with no traffic for the new node to get enough reputation and data.
Yeah, with less than 2% of probability
So, how come datacenters use RAID, backups and enterprise-grade hardware if it is possible to achieve 99.3% availability with almost zero data loss by using a single hard drive, desktop-grade hardware and no backups?
If the requirements were like v2 (up to a week of downtime, node loss does not result in money loss), then I would most likely run 6 nodes on separate drives instead of one node on RAID6 from those 6 drives. I did that with v2, because a failed node was not that big a deal, a new node would get data fairly quickly. With the v3 requirements it’s a bit different and I have to treat the node pretty much the same way as I would treat a virtual server of a regular customer. So, RAID, server-grade hardware, UPS etc. I would also have backups, if it was possible to do so.
Because data centers aren’t about availability, but instead about not losing ANY customer data. There is no separate protection layer once a (hypothetical) single drive in a data center fails - for that reason date centers have to rely on their own measures to ensure no data is lost.
Storj itself already offers redundancy, that is the purpose of the network. If I just shut down my node now, no data would be lost at all.
You are the 1% then.