История изменений

Полюбуйтесь на переписку со знаменитым Timeweb.Cloud (который btw. уже второй месяц подряд поднимает цены на 10-200+ процентов на многие свои сервисы) в части возможностей их DBasS по аварийному восстановлению на определённую точку во времени (PITR) и миграции из их облака, если что-то пойдёт не так …

Service: DB1 (Database)

Вопрос:

База данных могла создаться с ошибкой.

Почему?

И где гарантия, что потом не произойдёт чего -то подобного на проде?

Почему нужно пересоздавать, а не исправить то, что уже было создано возможно частично. Я понимаю, что пересоздать проще, но как доверять такому DBasS, который в случае сбоя нужно пересоздавать?

Ответ провайдера:

Наши специалисты видят эти ошибки и стараются исправлять в кратчайшее время. Но есть ошибки которые сложно отдебажить и быстро исправить, поэтому малая часть установок может завершиться неудачей.

Вопрос:

У вас бэкапы и WAL логи можно регулярно копировать к себе на другой сервер ?

Подразумевается из инстанса DBaaS

Ответ провайдера:

Нет, встроенные бэкапы и WAL‑журналы кластера нельзя выгружать или автоматически копировать на внешний сервер – они используются только внутри сервиса для восстановления и отказоустойчивости. Вместо этого можно настроить собственные регулярные дампы базы на ваш сервер или в другое хранилище.​

В кластерах DBaaS доступны автоматические и ручные бэкапы, которые создаются и хранятся на стороне сервиса и используются для восстановления кластера через панель управления. Текущая реализация не предусматривает скачивание этих резервных копий: их можно только использовать для восстановления, а не выгружать отдельным файлом или передавать на сторонний сервер.​

В панели управления доступны только текстовые логи PostgreSQL (ошибки, предупреждения, информационные сообщения), их можно просматривать и скачивать в виде .txt для диагностики. WAL‑журналы и механизмы репликации используются внутри управляемого кластера и не отдаются наружу, поэтому настроить собственную потоковую/архивную репликацию или логическую репликацию с этого кластера на внешний сервер нельзя.​

Если нужно регулярно получать копии данных на свой сервер, можно настроить отдельный сценарий резервного копирования: например, с вашего сервера по cron запускать pg_dump к кластеру DBaaS и сохранять дампы локально или в объектное хранилище. Такой подход позволит иметь собственные резервные копии вне DBaaS, при этом встроенные бэкапы и внутренняя репликация продолжат работать на стороне сервиса.

Вопрос:

Пожалуйста, уточните, как восстанавливтаь базу на PIT ? Т.е. как делать PITR?

Ответ провайдера:

Восстановление в DBaaS может выполняться из логических бэкапов, но не через PITR.

Можно также настроить автоматическое резервное копирование: https://timeweb.cloud/docs/dbaas/dbaas-manage#rezervnoe-kopirovanie-baz-dannyh

Вопрос:

Восстановление в DBaaS может выполняться из логических бэкапов, но не через PITR.

Добрый день,

Т.е. восстанавливать можно только из дампа, а если нужно только до определённой точки или наоборот до самого последнего момента (который наступил уже после дампа), то такое в Timeweb не получится?

Ответ провайдера:

Бэкапы создаются в фиксированное время и хранят информацию на момент их запуска и полную копию всех баз.

Восстановить базу на произвольное время через бэкапы не получится.

Можете использовать ручные бэкапы для этого или сохранять отдельные дампы с нужным состоянием вручную через клиента базы.

Полюбуйтесь на переписку со знаменитым Timeweb.Cloud (который btw. уже второй месяц подряд поднимает цены на 10-200+ процентов на многие свои сервисы) в части возможностей их DBasS по аварийному восстановлению на определённую точку во времени (PITR) и миграции из их облака, если что-то пойдёт не так …

Service: DB1 (Database)

Вопрос:

База данных могла создаться с ошибкой.

Почему?

И где гарантия, что потом не произойдёт чего -то подобного на проде?

Почему нужно пересоздавать, а не исправить то, что уже было создано возможно частично. Я понимаю, что пересоздать проще, но как доверять такому DBasS, который в случае сбоя нужно пересоздавать?

Ответ провайдера:

"И где гарантия, что потом не произойдёт чего -то подобного на проде?

Почему нужно пересоздавать, а не исправить то, что уже было создано возможно частично. Я понимаю, что пересоздать проще, но как доверять такому DBasS, который в случае сбоя нужно пересоздавать?"Благодарю за обратную связь.

Наши специалисты видят эти ошибки и стараются исправлять в кратчайшее время. Но есть ошибки которые сложно отдебажить и быстро исправить, поэтому малая часть установок может завершиться неудачей.

Вопрос:

У вас бэкапы и WAL логи можно регулярно копировать к себе на другой сервер ?

Подразумевается из инстанса DBaaS

Ответ провайдера:

Нет, встроенные бэкапы и WAL‑журналы кластера нельзя выгружать или автоматически копировать на внешний сервер – они используются только внутри сервиса для восстановления и отказоустойчивости. Вместо этого можно настроить собственные регулярные дампы базы на ваш сервер или в другое хранилище.​

В кластерах DBaaS доступны автоматические и ручные бэкапы, которые создаются и хранятся на стороне сервиса и используются для восстановления кластера через панель управления. Текущая реализация не предусматривает скачивание этих резервных копий: их можно только использовать для восстановления, а не выгружать отдельным файлом или передавать на сторонний сервер.​

В панели управления доступны только текстовые логи PostgreSQL (ошибки, предупреждения, информационные сообщения), их можно просматривать и скачивать в виде .txt для диагностики. WAL‑журналы и механизмы репликации используются внутри управляемого кластера и не отдаются наружу, поэтому настроить собственную потоковую/архивную репликацию или логическую репликацию с этого кластера на внешний сервер нельзя.​

Если нужно регулярно получать копии данных на свой сервер, можно настроить отдельный сценарий резервного копирования: например, с вашего сервера по cron запускать pg_dump к кластеру DBaaS и сохранять дампы локально или в объектное хранилище. Такой подход позволит иметь собственные резервные копии вне DBaaS, при этом встроенные бэкапы и внутренняя репликация продолжат работать на стороне сервиса.

Вопрос:

Пожалуйста, уточните, как восстанавливтаь базу на PIT ? Т.е. как делать PITR?

Ответ провайдера:

Восстановление в DBaaS может выполняться из логических бэкапов, но не через PITR.

Можно также настроить автоматическое резервное копирование: https://timeweb.cloud/docs/dbaas/dbaas-manage#rezervnoe-kopirovanie-baz-dannyh

Вопрос:

Восстановление в DBaaS может выполняться из логических бэкапов, но не через PITR.

Добрый день,

Т.е. восстанавливать можно только из дампа, а если нужно только до определённой точки или наоборот до самого последнего момента (который наступил уже после дампа), то такое в Timeweb не получится?

Ответ провайдера:

Бэкапы создаются в фиксированное время и хранят информацию на момент их запуска и полную копию всех баз.

Восстановить базу на произвольное время через бэкапы не получится.

Можете использовать ручные бэкапы для этого или сохранять отдельные дампы с нужным состоянием вручную через клиента базы.