Thread: вопрос о стратегии бэкапа

вопрос о стратегии бэкапа

From
Ivan
Date:
Hello,

  У меня возник ещё один вопрос, с которым сталкивались
все администраторы баз данных Postgresql: какую стратегию
для бэкапа лучше выбрать - sql-backup или On-line backup and
point-in-time recovery.
  Понимаю, что в каждом случае необходимо выбирать свою стратегию,
мой случай - ОС Windows, большая по размеру база (для сбора
и обработки статистики) - несколько Гб.
  Может кто поделится опытом.
  Спасибо!

--
Best regards,
 Ivan                          mailto:Ivan-Sun1@mail.ru


Re: вопрос о

From
Nick Gazaloff
Date:
Ivan wrote:
> Hello,
>
>   У меня возник ещё один вопрос, с которым сталкивались
> все администраторы баз данных Postgresql: какую стратегию
> для бэкапа лучше выбрать - sql-backup или On-line backup and
> point-in-time recovery.
>   Понимаю, что в каждом случае необходимо выбирать свою стратегию,
> мой случай - ОС Windows, большая по размеру база (для сбора
> и обработки статистики) - несколько Гб.

Насколько большие изменения данных проходят за сутки? Какой объем
хранения вы готовы выделить под backup? Какой период может быть
безболезненно потерян (день, час, никакой)?

>   Может кто поделится опытом.
>   Спасибо!
>


--

Best regards,
Nick
(GPG Key ID: 4396B2D0)


Hello,

NG> Насколько большие изменения данных проходят за сутки? Какой объем
NG> хранения вы готовы выделить под backup? Какой период может быть
NG> безболезненно потерян (день, час, никакой)?

Основные изменения - это вставка записей в одну таблицу базы
(остальные таблицы будут изменятся относительно редко).
За сутки будет производится вставка порядка 20 000 записей
(скорее всего в дальнейшем это число будет увеличиватся).
Под бэкап я думаю если понадобится будет выделено дополнительное
место (то есть это не является решающим фактором). Данные в
базу будут забиваться из текстовых логов, эти файлы некоторое
время ещё хранятся, так что потеря данных за месяц в принципе
некритична.

В данный момент я все больше склоняюсь к варианту с sql-бэкапом
(по причине более легкой автоматизации процесса бэкапа и
восстановления и в силу некритичности потери некоторых данных).
Однако здесь тоже имеется вопрос - если я делаю не plain sql-backup,
а custom - могу ли я быть уверен, что следующие релизы PostgreSQL
(как "минорные" так и "мажорные") будут корректно его понимать (то
есть не поменяется ли формат custom sql-backup'а)?

Еще вопрос: при размере базы в 10, 20 Gb (или более) является ли
целесообразным использовать sql-backup (ведь восстановление будет
занимать достаточно большое время) - хотя понятно что при миграции
на следующую версию сервера этого не избежать.

И не последним фактором является сложность организации бэкапа с
архивированием WAL-сегментов - может существуют утилиты, помогающие
в данном вопросе? Или если кто сам из подписчиков pgsql-ru-general
имеет опыт с организацией этого типа бэкапа и может поделится
наработками (особо интересует платформа WIN32 - однако и другие
варианты я думаю будут интересны не только мне). Если пока никто
не пробовал сделать это под WIN32 я думаю сам заняться этим вопросом
(рано или поздно придется :)) и поделюсь результатами.

Спасибо за любые советы, мнения и комментарии!

--
Best regards,
 Ivan                            mailto:Ivan-Sun1@mail.ru


Re: Re[2]: [pgsql-ru-general] вопрос

From
Oleg Bartunov
Date:
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-471396894-1107768359=:24337
Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 8BIT

Немного не в тему, но может поможет:
Есть еще одна алтернатива бэкапу - это реплицирование, которое
достаточно легко устроить при использовании прохи, которое раздает sql-запросы
парочке серверов. Заодно будете иметь и горячую подмену.

Олег
On Mon, 7 Feb 2005, Ivan wrote:

> Hello,
>
> NG> Насколько большие изменения данных проходят за сутки? Какой объем
> NG> хранения вы готовы выделить под backup? Какой период может быть
> NG> безболезненно потерян (день, час, никакой)?
>
> Основные изменения - это вставка записей в одну таблицу базы
> (остальные таблицы будут изменятся относительно редко).
> За сутки будет производится вставка порядка 20 000 записей
> (скорее всего в дальнейшем это число будет увеличиватся).
> Под бэкап я думаю если понадобится будет выделено дополнительное
> место (то есть это не является решающим фактором). Данные в
> базу будут забиваться из текстовых логов, эти файлы некоторое
> время ещё хранятся, так что потеря данных за месяц в принципе
> некритична.
>
> В данный момент я все больше склоняюсь к варианту с sql-бэкапом
> (по причине более легкой автоматизации процесса бэкапа и
> восстановления и в силу некритичности потери некоторых данных).
> Однако здесь тоже имеется вопрос - если я делаю не plain sql-backup,
> а custom - могу ли я быть уверен, что следующие релизы PostgreSQL
> (как "минорные" так и "мажорные") будут корректно его понимать (то
> есть не поменяется ли формат custom sql-backup'а)?
>
> Еще вопрос: при размере базы в 10, 20 Gb (или более) является ли
> целесообразным использовать sql-backup (ведь восстановление будет
> занимать достаточно большое время) - хотя понятно что при миграции
> на следующую версию сервера этого не избежать.
>
> И не последним фактором является сложность организации бэкапа с
> архивированием WAL-сегментов - может существуют утилиты, помогающие
> в данном вопросе? Или если кто сам из подписчиков pgsql-ru-general
> имеет опыт с организацией этого типа бэкапа и может поделится
> наработками (особо интересует платформа WIN32 - однако и другие
> варианты я думаю будут интересны не только мне). Если пока никто
> не пробовал сделать это под WIN32 я думаю сам заняться этим вопросом
> (рано или поздно придется :)) и поделюсь результатами.
>
> Спасибо за любые советы, мнения и комментарии!
>
>

     Regards,
         Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---559023410-471396894-1107768359=:24337--

Ivan wrote:
> Hello,
>
> NG> Насколько большие изменения данных проходят за сутки? Какой объем
> NG> хранения вы готовы выделить под backup? Какой период может быть
> NG> безболезненно потерян (день, час, никакой)?
>
> Основные изменения - это вставка записей в одну таблицу базы
> (остальные таблицы будут изменятся относительно редко).
> За сутки будет производится вставка порядка 20 000 записей
> (скорее всего в дальнейшем это число будет увеличиватся).

Каков размер записей (число и тип полей)?

> В данный момент я все больше склоняюсь к варианту с sql-бэкапом
> (по причине более легкой автоматизации процесса бэкапа и
> восстановления и в силу некритичности потери некоторых данных).
> Однако здесь тоже имеется вопрос - если я делаю не plain sql-backup,
> а custom - могу ли я быть уверен, что следующие релизы PostgreSQL
> (как "минорные" так и "мажорные") будут корректно его понимать (то
> есть не поменяется ли формат custom sql-backup'а)?

Да.

> Еще вопрос: при размере базы в 10, 20 Gb (или более) является ли
> целесообразным использовать sql-backup (ведь восстановление будет
> занимать достаточно большое время) - хотя понятно что при миграции
> на следующую версию сервера этого не избежать.

Пожалуй, восстановление из online backup (с относительно небольшой
историей) все же быстрее.

> И не последним фактором является сложность организации бэкапа с
> архивированием WAL-сегментов - может существуют утилиты, помогающие
> в данном вопросе? Или если кто сам из подписчиков pgsql-ru-general
> имеет опыт с организацией этого типа бэкапа и может поделится
> наработками (особо интересует платформа WIN32 - однако и другие
> варианты я думаю будут интересны не только мне). Если пока никто
> не пробовал сделать это под WIN32 я думаю сам заняться этим вопросом
> (рано или поздно придется :)) и поделюсь результатами.

Я сделал достаточно универсальный скрипт для online backup, на днях
доведу его до ума и выложу. Он на perl, но под Win32 это не проблема.


--

Best regards,
Nick
(GPG Key ID: 4396B2D0)