On 5/16/20 3:30 PM, Gavin Flower wrote:
On 17/05/2020 08:12, Ron wrote:
On 5/16/20 7:18 AM, Rob Sargent wrote:
O
Another problem is storage devices fail. S3 storage lakes _should_ be checking your data integrity on a regular basis and possibly maintaining copies of it iin multiple locations so you're not vulnerable to a site disaster.
Tape FTW!!
Or WTF Tape?? :)
Tape is durable, long-lasting, high-density, under your control, can be taken off-site (don't underestimate the bandwidth of a station wagon full of tapes hurtling down the highway!) and -- with the proper software -- is multi-threaded.
Don't you mean multi-spooled??? :-)
That's a superset of multi-threaded IO.
Fascinating problem. If the dump & load programs are designed to take a parameter for N drives for effective parallel operation, and N > 2, then things will run a lot faster.
I can think of several ways the the data can be dumped in parallel, with various trade-offs. Would love to know how it's implemented in practice.
An OS with asynchronous, queued, non-blocking IO, and a programming language with callbacks. OpenVMS has had it since since
at least the early 1990s, and probably mid-1980s. I remember backing up an Rdb/VMS database to 10 tape drives at the same time. Typically, though, we "only" used six tape drives for that database, because we simultaneously backed up multiple databases.
--
Angular momentum makes the world go 'round.
