Инкрементное резервное копирование на уровне блоков
Инкрементный бекап на уровне блоков -- хорошая альтернатива полному резервному копированию и непрерывному WAL-архивированию данных при соблюдении следующих условий:
- Количество измененных блоков невелико по сравнению с общим количеством блоков.
- Объем WAL- архива значительно превосходит объем измененнных блоков, что означает внесение изменений преимущественно в одни и те же блоки.
Ключевой вопрос - как получить карту изменений, совершенных с момента последнего резервного копирования блоков. Для этого есть несколько способов:
- Сделать полное сканирование всех блоков кластера базы данных для резервного копирования.
- Извлечь измененные блоки из WAL.
- Реализовать в PostgreSQL поддержку карты измененных блоков (либо битовую карту, либо LSN для каждой страницы).
Barman может реализовать пункт 1, но возникнет проблема высокой нагрузки ввода-вывода на кластер базы данных в процессе резервного копирования. Мы уже реализовали пункт 2 для pg_arman, но это решение требует архивирования WAL, что не всегда приемлемо. Теперь мы отказались от неинвазивных подходов и работаем над патчем для поддержания карты измененных блоков в PostgreSQL.
Проверка резервной копии
Многие пользователи жалуются, что по факту завершения резервного копирования на уровне файлов трудно проверить валидность копии. На самом же деле в резервной копии кластера базы данных можно проверить многое. Однако эти проверки должны происходить достаточно оперативно, чтобы была возможность сразу запускать систему после создания каждой резервной копии, и, вместе с тем, защитить от некоторых типичных ошибок.
Частичное резервное копирование и частичное восстановление данных
Текущее ограничение резервного копирования на уровне файлов позволяет сделать бекап только для кластера базы данных в целом. Но пользователи хотят иметь возможность сохранять только некоторые БД и восстанавливать отдельные БД в существующий кластер. Вторая функция потребует более серьезных изменений кода, например, переписать все xid в множестве БД, которые собираемся восстанавливать, но это выглядит более экономным способом по сравнению с pg_dump/pg_restore.