YS
занудно: вы бы картинки прикладывали нормально, чтобы можно было смотреть без скачивания
Промахнулся. :(
Size: a a a
2021 February 24
YS
Привет, подскажите, правильно ли я понимаю что для небольших БД (например до 1 гб) бекапы можно делать через стандартный pg_dump ?
И ещё раз. ;)
YS
требования обычные: каждый день нужно бекапнуть небольшую базу, залить ее на какое то внешнее хранилище
в доках просто только описаны pg_dump, полное копирование файлов пг на уровне фс и архивация, мне показалось что 2 и 3 слишком overkill для такой задачи. или нет? или как тогда лучше делать чтобы не было "dump is not a backup"?)
в доках просто только описаны pg_dump, полное копирование файлов пг на уровне фс и архивация, мне показалось что 2 и 3 слишком overkill для такой задачи. или нет? или как тогда лучше делать чтобы не было "dump is not a backup"?)
> каждый день нужно бекапнуть небольшую базу, залить ее на какое то внешнее хранилище
Это же не требования... Какие у вас RPO и RTO, хотя бы?
Это же не требования... Какие у вас RPO и RTO, хотя бы?
N
Yaroslav Schekin
> каждый день нужно бекапнуть небольшую базу, залить ее на какое то внешнее хранилище
Это же не требования... Какие у вас RPO и RTO, хотя бы?
Это же не требования... Какие у вас RPO и RTO, хотя бы?
расшифруйте rpo/rto :D
Z
я тоже послушаю
VY
прелестно!
YS
расшифруйте rpo/rto :D
Within business continuity, it is important to familiarize with two fundamental metrics, as defined by Wikipedia:
1. Recovery Point Objective (RPO): "maximum targeted period in which data might be lost from an IT service due to a major incident"
2. Recovery Time Objective (RTO): "the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity"
In a few words, RPO represents the maximum amount of data you can afford to lose, while RTO represents the maximum down-time you can afford for your service.
© "introduction" from barman (первое, что попалось).
А вообще, это основы профессии DBA. ;)
1. Recovery Point Objective (RPO): "maximum targeted period in which data might be lost from an IT service due to a major incident"
2. Recovery Time Objective (RTO): "the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity"
In a few words, RPO represents the maximum amount of data you can afford to lose, while RTO represents the maximum down-time you can afford for your service.
© "introduction" from barman (первое, что попалось).
А вообще, это основы профессии DBA. ;)
N
Yaroslav Schekin
Within business continuity, it is important to familiarize with two fundamental metrics, as defined by Wikipedia:
1. Recovery Point Objective (RPO): "maximum targeted period in which data might be lost from an IT service due to a major incident"
2. Recovery Time Objective (RTO): "the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity"
In a few words, RPO represents the maximum amount of data you can afford to lose, while RTO represents the maximum down-time you can afford for your service.
© "introduction" from barman (первое, что попалось).
А вообще, это основы профессии DBA. ;)
1. Recovery Point Objective (RPO): "maximum targeted period in which data might be lost from an IT service due to a major incident"
2. Recovery Time Objective (RTO): "the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity"
In a few words, RPO represents the maximum amount of data you can afford to lose, while RTO represents the maximum down-time you can afford for your service.
© "introduction" from barman (первое, что попалось).
А вообще, это основы профессии DBA. ;)
так я не DBA :D
VY
а не завести ли бота, которого обучить основным понятиям/терминам/ссылкам. чтобы не копипастить постоянно
YS
так я не DBA :D
Я к тому, что это всё равно цель, а всякие разные "backup-ы" — только возможные средства её достижения.
YS
Лучше бы какой-то FAQ завели, а ссылку добавили в описание чата.
YS
а не завести ли бота, которого обучить основным понятиям/терминам/ссылкам. чтобы не копипастить постоянно
Но бот — тоже очень неплохо. В других чатах такое есть, а базу знаний можно было бы попросить от pg_docbot (из IRC). :)
Z
прочитал, спасибо, но в любом случае . вариантов бекапа не очень много. RAID, pgdump, файловый, стриминговая репликация, логическая репликация. и их сочетания.
MM
А можно я вылезу с вопросом про бекапы? Есть сервер, на нем лежит 2 БД. Продакшен и тест. Общий размер на FS - 72 гига. Продакшен - из них занимает 42Гб. В сжатом виде архив от pg_dump прода занимает около 5.5Гб. Снятие дампов через pg_dump очень не нравится, так как разворачивается до 40 минут. Сами данные восстанавливаются относительно быстро, а вот индексы, и форинкеи - это долго. Сейчас дамп снимается раз в сутки, но это как-то слишком редко. Хотелось бы чаще и быстрее в плане восстановления, так как ждать разворота БД такое время слишком критично. Новые данные поступают в систему почти непрерывным потоком. RAM на машинке - 128Гб, хранилище - зеркало на SSD
MM
Кто может посоветовать какой-то реальный кейс?
🔥Э
Кто может посоветовать какой-то реальный кейс?
Репликация. Ещё одну машину ставить
MM
Репликация. Ещё одну машину ставить
12-й умеет master-master ?
VY
Репликация. Ещё одну машину ставить
ну вот есть у вас репликация. как быть если:
- надо восстановиться на время 1 час назад?
- кто-то грохнул таблицу в мастере?
- надо восстановиться на время 1 час назад?
- кто-то грохнул таблицу в мастере?
VY
12-й умеет master-master ?
при чём тут мастер-мастер?