А вот streaming репликация гоняет несжатые данные.
Кажется, что при включенном wal_compression и full_page_writes оно-таки жмёт в случае со streaming-replication. И судя по интернетам - даже на pglz вполне заметно. На 15-ой версии уже и lz4/zstd завезли, так что результаты могут оказаться ещё более интересными.
В случае если для хранения бэкапов используются ленты — Bacula практически единственный вариант.
И справедливости ради, стоит добавить, что Bacula поддерживает клиента для AIX.
Bacula Enterprise по сравнению с Bacula Community умеет несколько полезных плюшек: Oracle Plugin, Block-level incremental Plugin.
Но плагины не под всем ОС работают, оракловый, например, работает только на линукс-серверах.
Ценник вполне адекватный, но как ни парадоксально, Oracle Secure Backup вышел в 2 раза дешевле с перманентной лицензией.
вы чересчур поверхностно и легкомысленно смотрите на проблему резервного копирования.
У меня нет проблем ни с копированием, ни с восстановлением.
Разговор зашёл в тупик на мой взгляд, если ваш опыт вам говорит о надёжности дисков — ваше право. Я оставляю за собой право иметь другое мнение по этому вопросу.
А спустя 2 минуты на площадке загорается ЦОД, где стоит леточная библиотека.
Что вы пытаетесь доказать? Случаи какие-то пограничные… Что с дисковым массивом будет при аналогичных проишествиях?
На какой момент вам удастся восстановиться без этой ленты?
24 часа максимальный откат по данным будет в таком случае. Придётся накатывать arch-логи за пару суток, но это не так страшно в подобной ситуации.
Тем более непонятно
Вы судите по единственному приведённому мной примеру о суммарном размере ежедневных бэкапов?
У меня 2 ленточных бибилотеки, HP и IBM, 2500 и 680 суток аптайма соответственно. За это время один раз в драйве заклинило ленту, его замена заняла 2 суток. Кассеты не умирали вообще.
И теперь оно внезапно стало ненадёжным?
Писать одновременно несколько потоков, практически полностью нагружая ленту.
Наихудший случай при full-incremental это:
Не совсем, у меня Full-бэкап на ленте — это несколько rman-овских full-бэкапов с arch-логами между ними. Оракловый full-бэкап есть на инкрементальных лентах и он делается каждый день, благо дисковая подсистема позволяет это сделать без потери производительности.
Переключение кассеты роботом занимает около 1 минуты, учитывая, что таких переключений может быть максимум 4, учитывая перемотку это добавит ну минут 7, да даже 10.
В своём сценарии вы предполагаете крайний вариант экономии лент. Я забираю Full-бэкапы баз каждый день.
Я в этом топике слишком часто упоминаю бакулу, просто хотел сказать, что мне за это не платят =)
Так вот, она — умеет. Подробной статистики нет, посчитать максимальную скорость можно только по средней температуре по больнице, но на порядки расхождений там не будет.
Ну что-то все же мешает, так как никто этого не делает. Вот вы — делаете? ;)
Тут я попался, что сказать… У бакулы не существует протокола общения между двумя SD (Storage Daemon, который как раз на ленту пишет). Но если говорить о коммерческих системах резервного копирования — такой функционал есть (и за его игнорирование нужно больно бить).
Подтверждение на практике — делали?
К сожалению — проверяли в самых что ни на есть реальных условиях. Вытягивание бэкапа 20Гб базы с ленты около 10 минут, его восстановление около 10-15 минут (этим уже DBA занимаются). Давно учений не было, точнее не скажу.
На самом деле не так много времени на неё уходит. Я не говорю, что она идеальна — нет, с точки зрения удобства использования — один из самых неприятных продуктов, однако — она работает, и работает довольно хорошо.
Чтобы не быть голословным, могу сказать — с нулевым опытом работы с бакулой разбор с «наследием царского режима» занял около 1,5 недель. Повседневной работы с ней нет, только если что-то надо улучшить или восстановить.
Мне было бы приятней, если бы была какая-то энтерпрайзная софтина с удобным интерфейсом, но стоят они крайне дорого и часто не всё умеют.
Тут вы не правы, зависит от типа данных. В случае, например, с бэкапом здоровенной базы — очень даже выигрывает.
Это если мы говорим о решениях с приблизительно одинаковой стоимостью на гигабайт бэкапа.
особенно если они с интерливингом и на разных лентах
Можно использовать библиотеки с несколькими приводами.
RAID-то нет
Никто не мешает делать копии лент или конкретных бэкапов между этими лентами.
И в конце-концов, есть различные стратегии бэкапов, у меня, например, всё просто и примитивно — Full+Incremental пулы. В бэкапах в основном оракловые базы. И нам доступно ЛЮБОЕ состояние базы за последние 3 месяца. А за последние 3 недели мы получим бэкап даже если одну или несколько лент зажует привод.
Не хочу показаться грубым, но концепция не представляет из себя ничего нового — это стандартный подход к резервному копированию БД.
Это, конечно, всяко лучше обзора телефончика, но всё же — зачем этот пост нужен?
В нём нет ничего нового, и если уж он является описанием «концепции», то почему нет полной схемы организации резервного копирования?
Некорректен сам подход: измерение объективных метрик при сжатии звука с потерями.
При сжатии с потерями используются психоакустические модели. В результате получается уже объективно искажённый сигнал, но субъективно искажения не заметны.
При идеальных условиях PSNR покажет снижение уровня сигнала, корреляция тоже будет ниже 1. А субъективное качество — идеальным.
Кажется, что при включенном wal_compression и full_page_writes оно-таки жмёт в случае со streaming-replication.
И судя по интернетам - даже на pglz вполне заметно. На 15-ой версии уже и lz4/zstd завезли, так что результаты могут оказаться ещё более интересными.
1. qemu-ga (guest agent) freeze-fs
2. snapshot хранилища образов ВМ на гипервизоре
3. qemu-ga unfreeze-fs
4. Бэкап
5. удаление snapshot
У меня CentOS 6, но не думаю, что в Ubuntu не этого функционала.
И справедливости ради, стоит добавить, что Bacula поддерживает клиента для AIX.
Bacula Enterprise по сравнению с Bacula Community умеет несколько полезных плюшек: Oracle Plugin, Block-level incremental Plugin.
Но плагины не под всем ОС работают, оракловый, например, работает только на линукс-серверах.
Ценник вполне адекватный, но как ни парадоксально, Oracle Secure Backup вышел в 2 раза дешевле с перманентной лицензией.
Перешёл на Canon-овские утилиты.
У меня нет проблем ни с копированием, ни с восстановлением.
Разговор зашёл в тупик на мой взгляд, если ваш опыт вам говорит о надёжности дисков — ваше право. Я оставляю за собой право иметь другое мнение по этому вопросу.
Что вы пытаетесь доказать? Случаи какие-то пограничные… Что с дисковым массивом будет при аналогичных проишествиях?
24 часа максимальный откат по данным будет в таком случае. Придётся накатывать arch-логи за пару суток, но это не так страшно в подобной ситуации.
Вы судите по единственному приведённому мной примеру о суммарном размере ежедневных бэкапов?
У меня 2 ленточных бибилотеки, HP и IBM, 2500 и 680 суток аптайма соответственно. За это время один раз в драйве заклинило ленту, его замена заняла 2 суток. Кассеты не умирали вообще.
И теперь оно внезапно стало ненадёжным?
Писать одновременно несколько потоков, практически полностью нагружая ленту.
Не совсем, у меня Full-бэкап на ленте — это несколько rman-овских full-бэкапов с arch-логами между ними. Оракловый full-бэкап есть на инкрементальных лентах и он делается каждый день, благо дисковая подсистема позволяет это сделать без потери производительности.
Переключение кассеты роботом занимает около 1 минуты, учитывая, что таких переключений может быть максимум 4, учитывая перемотку это добавит ну минут 7, да даже 10.
В своём сценарии вы предполагаете крайний вариант экономии лент. Я забираю Full-бэкапы баз каждый день.
Я в этом топике слишком часто упоминаю бакулу, просто хотел сказать, что мне за это не платят =)
Так вот, она — умеет. Подробной статистики нет, посчитать максимальную скорость можно только по средней температуре по больнице, но на порядки расхождений там не будет.
Тут я попался, что сказать… У бакулы не существует протокола общения между двумя SD (Storage Daemon, который как раз на ленту пишет). Но если говорить о коммерческих системах резервного копирования — такой функционал есть (и за его игнорирование нужно больно бить).
К сожалению — проверяли в самых что ни на есть реальных условиях. Вытягивание бэкапа 20Гб базы с ленты около 10 минут, его восстановление около 10-15 минут (этим уже DBA занимаются). Давно учений не было, точнее не скажу.
Чтобы не быть голословным, могу сказать — с нулевым опытом работы с бакулой разбор с «наследием царского режима» занял около 1,5 недель. Повседневной работы с ней нет, только если что-то надо улучшить или восстановить.
Мне было бы приятней, если бы была какая-то энтерпрайзная софтина с удобным интерфейсом, но стоят они крайне дорого и часто не всё умеют.
Тут вы не правы, зависит от типа данных. В случае, например, с бэкапом здоровенной базы — очень даже выигрывает.
Это если мы говорим о решениях с приблизительно одинаковой стоимостью на гигабайт бэкапа.
Можно использовать библиотеки с несколькими приводами.
Никто не мешает делать копии лент или конкретных бэкапов между этими лентами.
И в конце-концов, есть различные стратегии бэкапов, у меня, например, всё просто и примитивно — Full+Incremental пулы. В бэкапах в основном оракловые базы. И нам доступно ЛЮБОЕ состояние базы за последние 3 месяца. А за последние 3 недели мы получим бэкап даже если одну или несколько лент зажует привод.
Это, конечно, всяко лучше обзора телефончика, но всё же — зачем этот пост нужен?
В нём нет ничего нового, и если уж он является описанием «концепции», то почему нет полной схемы организации резервного копирования?
Вместо архивирования WAL — сетевое хранилище, куда мастер пишет (!) WAL-логи. К чёрту производительность!
Для надёжности надо ленточные библиотеки использовать.
При сжатии с потерями используются психоакустические модели. В результате получается уже объективно искажённый сигнал, но субъективно искажения не заметны.
При идеальных условиях PSNR покажет снижение уровня сигнала, корреляция тоже будет ниже 1. А субъективное качество — идеальным.