Re: Problem with Online-Backup

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: Problem with Online-Backup
Дата
Msg-id 45C38276.3020609@cox.net
обсуждение исходный текст
Ответ на Problem with Online-Backup  (roopa perumalraja <roopabenzer@yahoo.com>)
Ответы Re: Problem with Online-Backup  ("Joshua D. Drake" <jd@commandprompt.com>)
Список 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-----

В списке pgsql-general по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: Predicted lifespan of different PostgreSQL branches
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Re: pgAdmin III and pgpass was I "might" have found a bug on 8.2.1 win32