Re: Problem with Online-Backup

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Problem with Online-Backup
Date: 2007-02-02 18:27:02
Message-ID: 45C38276.3020609@cox.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/02/07 12:07, Lincoln Yeoh wrote:
> At 09:36 AM 2/2/2007, Ron Johnson wrote:
>> >
>> > OTOH, I still take a full base backup every night and keep ten days
>> > worth of WAL files on our backup server, so I guess maybe I don't
>> > *completely* trust it :-)
>>
>> Or you don't trust tape to be 100% reliable.
>
> Well so far tapes get chewed up by drives at intervals that are not far
> apart enough for me. And I've heard horror stories of tapes not being
> restorable using a different drive but same model etc (just not the same
> physical drive used for the backup).
>
> I suppose these problems are fixed by now in the latest tape drives, or
> were just "urban legends"? Right? *looks about nervously*...

Depends on the tape system. We've been using DLT (and SuperDLT) for
years and have never had any problems.

> Nowadays I also wonder about the restoration times of say 200GB or even
> TBs of data from backups. More fun if there are Very Important and
> Influential People popping in every 15 minutes to ask whether it's done
> yet.

That's a problem with pg. pg_dump is single-threaded and can only
write out to one file/device.

Now that PITR-from-WAL is in place, there are people who swear that
tarring up data directories, and then WAL-log rolling them forward
works perfectly. If your database uses tablespaces and is spread
across multiple disk devices, then you could probably speed the
backup/restore by parallel tarring each device data tree to it's own
tape drive. 6 LTO tape drives and your TB database gets backed up
up right quickly.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFw4J2S9HxQb37XmcRAkcvAKDCyMOkc2iRd8S6tW66su3pcRIAhQCgyc/0
CSrDgO5lnW+2KZpduyVgFJM=
=c4Lx
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Magnus Hagander 2007-02-02 18:32:10 Re: Re: pgAdmin III and pgpass was I "might" have found a bug on 8.2.1 win32
Previous Message Bruno Wolff III 2007-02-02 18:20:54 Re: Defining and Using variables in a postgres function