Комментарии 14
а чем ваше решение отличается от штатных средств копирования?
CommVault — это суровый энтерпрайз, когда количество объектов бекапирования сильно больше количества адекватных спецов, которые могли бы сделать тоже самое используя простые инструменты. Т.е. CommVault для одной базы, какой бы большой она ни была, не нужен.
А можно вопросик? Zalando — enterprise? А Яндекс? А Авито?
Просто в моем понимании, суровый энтерпрайз — это какие-то консервативные области вроде авиации, банковского дела, нефтянки. У которых не было необходимости изменяться быстро в прошлом, т.к. и там все ОК. Мои примеры выше — это чисто коммерсы, которые возможно начинали как стартапы.
Просто в моем понимании, суровый энтерпрайз — это какие-то консервативные области вроде авиации, банковского дела, нефтянки. У которых не было необходимости изменяться быстро в прошлом, т.к. и там все ОК. Мои примеры выше — это чисто коммерсы, которые возможно начинали как стартапы.
В статье сказано, что решение использовалось для бэкапа всех ресурсов компании. Статья только про PostgreSQL.
Выше в статье по этому поводу есть детальное описание. Кратко:
1. Используется единое решение для резервного копирования.
2. Есть возможность перемещать резервные копии на более дешёвые накопители (СХД, ленты и т.п.).
3. Используется дедупликация для хранения резервных копий, что позволяет экономить пространство на СХД.
4. В ПО для резервного копирования есть функционал по отслеживанию процесса резервного копирования и оповещения о результатах.
1. Используется единое решение для резервного копирования.
2. Есть возможность перемещать резервные копии на более дешёвые накопители (СХД, ленты и т.п.).
3. Используется дедупликация для хранения резервных копий, что позволяет экономить пространство на СХД.
4. В ПО для резервного копирования есть функционал по отслеживанию процесса резервного копирования и оповещения о результатах.
А есть размеры копий, который были выполнены «старым» способ и какие они сейчас? Много ли толку от «дедупликация»…
У нас, например, 400 гиговая база превращается в 30 гиговый дамп с помощью штатных «компрессоров». И еще скажите, пожалуйста, сильно ли отличается время восстановления из копии в отличии от того же pg_restore?
Ничего нового, кроме п.1.
Все остальное реализуется ± стандартными средствами ОС и БД при помощи небольшого количества работы ops'а по автоматизации.
Что хуже — CommVault не представляет себе специфику приложений, которые работают с БД… Поэтому кастомные решения выглядят более привлекательно.
Если же речь про "кровавый" энтерпрайз, который покупает коробки… То вероятность увидеть там Oracle или MS SQL сильно выше, чем PostgreSQL
Это хорошо подходит для небольших БД, так как сливать раз в сутки бэкап БД размером в 15-20 ТБ уже так не выйдет. С свое время реализовывал бэкап больших БД через снапшоты на хранилках
Можно и 20 и 30 и 100 Тб бэкапить через бэкап системы типа NetBackup или CommVault, просто тут возникают некоторые тонкости и особенности. У нашего клиента есть базы на MSSQL размером в 100 Tb и как бы проблем нет, используется NetBackup, как я уже сказал на таких объёмах есть свои тонкости.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статья про то, как CommVault делает бэкап PostgreSQL