| From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
|---|---|
| To: | |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Inherited an 18TB DB & need to backup |
| Date: | 2020-05-16 20:30:36 |
| Message-ID: | 686bfa77-069f-e65a-8fab-d982d7284c88@archidevsys.co.nz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgeu-general pgsql-general |
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??? :-)
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.
Cheers,
Gavn
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron | 2020-05-17 04:05:37 | Re: Inherited an 18TB DB & need to backup |
| Previous Message | Ron | 2020-05-16 20:12:14 | Re: Inherited an 18TB DB & need to backup |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hugh | 2020-05-16 22:45:16 | Ubuntu 20.04: apt.postgresql.org/pub/repos/apt focal-pgdg InRelease' doesn't support architecture 'i386' |
| Previous Message | Ron | 2020-05-16 20:12:14 | Re: Inherited an 18TB DB & need to backup |