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.
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.
No it doesn't. Github has at least 20 million public repositories. Would they benefit by combining them into a monorepo?
And yes, a monorepo is usually the best approach in most cases for a project or even an entire company.
> a backup, or data backup is a copy of computer data taken and stored elsewhere so that it may be used to restore the original after a data loss event
Since a "replica" is a copy, that seems technically correct.
The original claim was "a backup is a replication of the live dataset, although, usually out of sync to be useful when the main dataset goes bad."
The only thing that makes a replica special is that it's in sync. Once you add the caveat that it's out of sync, it's just a copy.
Let's say a typical admin of a small shop wants to backup his postgres database.
The first thing he'll use is probably pg_dumpall which he'll output to a storage.
No replication involved. The backup is just a bunch of sql statements to recover the last known state of the database. It's a different kind of format however, which -by definition- isn't a replica anymore.
(And this process has several caveat's-one of which is that it can produce unusable dumps in some rare cases and isn't complete. users, triggers etc aren't dumped iirc.. could be wrong there)
All non-trivial replication has to cross machine boundaries. To transmit to another machine, you have to use a serial format since there are no pointers on the wire. So insisting that a replica must be the same format prohibits the concept of replication in practice.
How is it a copy if it can't recover the original in some cases?
We're not talking about a compressed archive here, it's a (incomplete) step-by-step instruction to recreate the data. If anything out of norm happens, it's gonna fail-possibly silently.
Do you think a gun is not a gun if it sometimes jams?
> We're not talking about a compressed archive here
I think we have two camps. Mine is considering "copy", "backup", "replica" to be broad categories that are distinguished by simple mathematical or technical properties. For instance, I'd consider a device that copied a single bit to be "copying," even though it's arguably just a wire.
The other camp has very specific products and tasks in mind. A replica is associated with distributed computing, while a backup is something a systems administrator makes as part of disaster recovery.
but a pgdump is like a step by step guide for building the gun, leaving out a lot of the process... how can you honestly call that a gun?
but i guess we'll have to agree to disagree. which proves that it was a discussion we shouldn't have started i guess.
Triggers are dumped, users need pg_dumpall (as they live across multiple databases, same with tablespaces).
You probably should look up the definition of “replication”.
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.