Comment by Eikon
6 years ago
> We sincerely apologize for the inconvenience that this situation has caused. This type of incident is extremely rare in the web hosting industry.
Why are they speaking of the "industry" as a whole when they are to blame?
It's even crazier they are not even explaining the source of the data loss and why the "replication systems" didn't help.
IHMO they are trying to sweep this event under the carpet. They should instead explain why they should be trusted in the future and why this would not occur again.
yeah, I worked for several years at a hosting provider, and I can tell you for a fact that this wouldn't have happened there.
They're 100% virtualized and keep backups of all those machines. In addition, you can purchase a package so that YOUR backups are automatically backed up to 2 different datacenters. Between the two of those solutions, there would be a way forward.
I don't really know what Gandi is so I can't speak to them directly, but this is a solvable problem.
Replication is explicitly designed to correct issues associated with bitrot and add redundancy.
Replication is not a backup as was already mentioned. A great example of this is when the KDE project almost lost all of their Git repos because they were mirroring a corrupted copy of the data. https://www.phoronix.com/scan.php?page=news_item&px=MTMzNTc
Fortunately, git is a DVCS, so anyone who checks out a repo has a complete copy of it.
Now, granted, it'd be a huge pain to track down all the people who had copies of the 1,500 different repos, and try to find as up-to-date as possible of a version of each, but I doubt they got anywhere close to potentially losing all their source code.
Incidentally this shows why it's a good idea to sync your repo to GitHub, even if the canonical repo is elsewhere: in addition to the usual reasons of incentivizing some contributors by giving them "GitHub credit", and increasing visibility of your project's code, GitHub can serve as a backup!
Also, on a side-note, 1,500 separate repositories?! That sounds way overkill. I wonder if they'd benefit from having a monorepo.
> 1,500 separate repositories?! That sounds way overkill. I wonder if they'd benefit from having a monorepo.
No it doesn't. Github has at least 20 million public repositories. Would they benefit by combining them into a monorepo?
1 reply →
A backup is a replication of the live dataset, although, usually out of sync to be useful when the main dataset goes bad.
You might want to read the Wikipedia definition, because you're technically mistaken.
https://en.m.wikipedia.org/wiki/Backup
14 replies →
The out of sync part is rather important when something accidently get deleted from the live dataset.
In the last few years, I have seen many people confuse replication with backups. People see them as the same thing, but they really aren't. Even with snapshots, if the devices are the same, they might have the same firmware bug, etc.
Just to further explore that a bit, would you say replication adds independent copies for failures of media, while backup adds copies made by independent software against failures of process / software / media.
Replication increases risk of data loss when implemented incorrectly, because added resources increase the probability of bit errors. This applies to both replicated disks (RAID) and servers. Replicated servers must use ECC memory as well as checksum blocks and periodically scrub data to ensure integrity (e.g. what ZFS does for you). If they don't then a bit error corrupts the data on all servers, because you have no way of know which copies are pristine or how to piece together pristine parts.
Replication covers durability (and availability) in face of system or media failure but does nothing whatsoever against software bugs or human error.