Pull to refresh

Comments 16

Хороший обзор и классификация. Спасибо.
Я бы ещё добавил про копирование файлов при создании резервной копии, что есть слой, обеспечивающий взаимодействие СУБД с файловой системой. Например, сказал бы пару слов про Volume Shadow Copy Services (VSS) в случае Windows.

Про снимок файловой системы там сказано. Правда, без конкретизации торговых марок.

Вывод — ни в коем случае не пропускайте сепуление, а сепульки храните в правильных сепулькариях.

Ваш вывод ошибочен — ибо — "БРЫНЗОВЕЛОСТЬ НЕ ПРИБЛИЖАЕТ ПАБЛОСУРЖИК!"

Вы один?
[смотрит на комментатора так, будто тот сказал что-то неприличное]

UFO just landed and posted this here
Это же своего рода архивная библиотека, и она же сразу визуальная картотека.

Если не секрет — откуда переводили?
Потому что с инкрементальными/дифференциальными/кумулятивными копиями у вас получилась полная каша. Например:


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

Это не перевод, это полностью оригинальный текст.
Всё правильно: инкрементальная копия — это изменения с какого-то места. Если с предыдущего инкремента, то дифференциальная, если с полной — то кумулятивная.

Нет. В общем смысле инкрементальная копия — это изменения относительно последней копии. Дифференциальная — относительно последней полной копии. Но не стоит говорить, что дифференциальная копия — тоже инкрементальная. Это не так.
Хотя в разных СУБД терминология не особо стыкуется, это верно. Но вы нигде не найдёте, например, чтобы differential backup для того же mssql называли incremental. Для mysql используются оба понятия, но со смыслом из моего первого абзаца.

Я ввожу собственную терминологию и объясняю её.
Больше всего она похожа на ту, что применяет Oracle – так получилось, что с этой СУБД я знаком лучше всего.
И если вы внимательно посмотрите табличку, то увидите, что как раз Oracle называет словом differential совсем не то, что MS SQL, а DB2 называет словом incremental то, что MS SQL называет differential.
Так что пусть сначала производители договорятся между собой :))
В отличие от многих похожих вопросов, вопрос «какой метод резервного копирования лучше» имеет однозначный ответ – лучше всего родная для используемой СУБД утилита, обеспечивающая возможность инкрементального копирования.

К сожалению, не у всех есть под рукой DBA админы, тогда на помощь приходят СРК(типа veeam), они прекрасно консистентно (если надо и редологи тоже) бекапят базы данных.
Системы резервного копирования (veeam, Microfocus DataProtector, Veritas NetBackup) – это совершенно отдельный класс программного обеспечения. Их задача – управление расписанием и системами хранения данных. А ещё они умеют интегрироваться со штатными средствами резервного копирования БД, с помощью которых, собственно, и делают консистентные копии баз.
Ну и статья – она не инструкция для дежурных администраторов, а объяснение принципов, лежащих в основе.

В постгресе есть только один тип бекапа: физический, выполняемый либо pg_basebakup, либо какими-либо другими подобными средствами.
pg_dump, pg_dumpall — это СНИМОК БД на момент старта. Исходя из требования возможности восстановления данных из резервной копии на любой момент времени после создания полного бекапа, таковым не является. Потому что из дампа восстанавливается только дамп, и ничего более. Увы и ах.
Соответственно, "двоичная формат", указанный в таблице именно для ПГ — это тот же самый текстовый, только отформатированный при выводе, как указано ключами командной строки. И не более того!
Также весьма интересно отсутствие весьма распространённого средства для бекапа MySQL, называемого Percona XtraBackup.
Автор взялся за писанину, имея за плечами что-то одно, не буду даже гадать, что. Но точно не MySQL и его форки (Percona и MariaDB), и не PostgreSQL. Путается в терминологии, однако. Особенно умиляет вот это:


Я ввожу собственную терминологию и объясняю её.

Для зачем? Вопрос далеко не праздный, и совсем не с однозначным ответом. Лично я предпочитаю не умничать, а изучать продукт, когда он попадает мне в руки, начиная, в первую очередь, с терминологии. Что и всем остальным настоятельно рекомендую, ибо в чужой монастырь со своим уставом не ходят.

За наводку на Percona XtraBackup – спасибо.
Остальной текст оставлю без ответа – надеюсь, что когда вы немного подрастёте, вам станет за него стыдно.
Sign up to leave a comment.

Articles