Comments 16
Я бы ещё добавил про копирование файлов при создании резервной копии, что есть слой, обеспечивающий взаимодействие СУБД с файловой системой. Например, сказал бы пару слов про Volume Shadow Copy Services (VSS) в случае Windows.
Если не секрет — откуда переводили?
Потому что с инкрементальными/дифференциальными/кумулятивными копиями у вас получилась полная каша. Например:
Очевидно, что объём одной кумулятивной копии меньше, чем объём нескольких дифференциальных копий, потому что некоторые страницы изменились по несколько раз, и каждая инкрементальная копия содержит свою версию страницы.
Это не перевод, это полностью оригинальный текст.
Всё правильно: инкрементальная копия — это изменения с какого-то места. Если с предыдущего инкремента, то дифференциальная, если с полной — то кумулятивная.
Нет. В общем смысле инкрементальная копия — это изменения относительно последней копии. Дифференциальная — относительно последней полной копии. Но не стоит говорить, что дифференциальная копия — тоже инкрементальная. Это не так.
Хотя в разных СУБД терминология не особо стыкуется, это верно. Но вы нигде не найдёте, например, чтобы differential backup для того же mssql называли incremental. Для mysql используются оба понятия, но со смыслом из моего первого абзаца.
Больше всего она похожа на ту, что применяет Oracle – так получилось, что с этой СУБД я знаком лучше всего.
И если вы внимательно посмотрите табличку, то увидите, что как раз Oracle называет словом differential совсем не то, что MS SQL, а DB2 называет словом incremental то, что MS SQL называет differential.
Так что пусть сначала производители договорятся между собой :))
В отличие от многих похожих вопросов, вопрос «какой метод резервного копирования лучше» имеет однозначный ответ – лучше всего родная для используемой СУБД утилита, обеспечивающая возможность инкрементального копирования.
К сожалению, не у всех есть под рукой DBA админы, тогда на помощь приходят СРК(типа veeam), они прекрасно консистентно (если надо и редологи тоже) бекапят базы данных.
Ну и статья – она не инструкция для дежурных администраторов, а объяснение принципов, лежащих в основе.
В постгресе есть только один тип бекапа: физический, выполняемый либо pg_basebakup, либо какими-либо другими подобными средствами.
pg_dump, pg_dumpall — это СНИМОК БД на момент старта. Исходя из требования возможности восстановления данных из резервной копии на любой момент времени после создания полного бекапа, таковым не является. Потому что из дампа восстанавливается только дамп, и ничего более. Увы и ах.
Соответственно, "двоичная формат", указанный в таблице именно для ПГ — это тот же самый текстовый, только отформатированный при выводе, как указано ключами командной строки. И не более того!
Также весьма интересно отсутствие весьма распространённого средства для бекапа MySQL, называемого Percona XtraBackup.
Автор взялся за писанину, имея за плечами что-то одно, не буду даже гадать, что. Но точно не MySQL и его форки (Percona и MariaDB), и не PostgreSQL. Путается в терминологии, однако. Особенно умиляет вот это:
Я ввожу собственную терминологию и объясняю её.
Для зачем? Вопрос далеко не праздный, и совсем не с однозначным ответом. Лично я предпочитаю не умничать, а изучать продукт, когда он попадает мне в руки, начиная, в первую очередь, с терминологии. Что и всем остальным настоятельно рекомендую, ибо в чужой монастырь со своим уставом не ходят.
Путеводитель по резервному копированию баз данных