Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Аня вообще няшка у вас )
Расскажите, как вы сделали прогрессбар на cmd?
Доброго времени суток.
Скажите, пожалуйста, под какой лицензией распространяется PackDb?
Скажите, пожалуйста, под какой лицензией распространяется PackDb?
Я правильно понял, что поддерживается также и восстановление?
Проводили ли вы сравнение с процедурой сохранения\восстановления стандартными средствами (+сжатие)? Конечно же интересует время выполнения.
Проводили ли вы сравнение с процедурой сохранения\восстановления стандартными средствами (+сжатие)? Конечно же интересует время выполнения.
Да, конечно, восстановление поддерживается. Время выполнения примерно равно сжатию, сам бекап не оказывает существенного влияния на скорость операции.
а конкретные цифры и примеры?
попробовал протестировать на паре баз 10-20Гб (сравнивал с бэкапом и восстановлением стандартными средствами SQL с включенным сжатием):
— бэкап 7z (5-6 мин) дольше стандартного (2.5-3 мин) в 2 раза, размер меньше в 1.5-2
— бэкап zip дольше в 2 раза, размер сопоставим со стандартным
— восстановление 7z с уровнем компрессии fast (3 мин) в 2 раза медленнее стандартного (1.5 мин)
Параметр сжатия пробовал только fast\low, все что выше выдавало неприемлемую оценку по времени в 30-40 мин и я не дождался.
Восстановление из архива zip завершилось с ошибкой и открыть архив тоже не получилось.
попробовал протестировать на паре баз 10-20Гб (сравнивал с бэкапом и восстановлением стандартными средствами SQL с включенным сжатием):
— бэкап 7z (5-6 мин) дольше стандартного (2.5-3 мин) в 2 раза, размер меньше в 1.5-2
— бэкап zip дольше в 2 раза, размер сопоставим со стандартным
— восстановление 7z с уровнем компрессии fast (3 мин) в 2 раза медленнее стандартного (1.5 мин)
Параметр сжатия пробовал только fast\low, все что выше выдавало неприемлемую оценку по времени в 30-40 мин и я не дождался.
Восстановление из архива zip завершилось с ошибкой и открыть архив тоже не получилось.
Смотрите, тут дело в том, что вы можете получить 7z быстрее и проще чем стандартными средствами (и не тратить место на диске). А потом этот 7z восстановить не распаковывая. А т.к. 7z жмёт гораздо лучше чем zip и стандартные средства, для долговременного хранения лучше использовать его (если есть время). Ну или для быстрых бекапов уменьшить качество сжатия.
По цифрам.
Вариант раз на слабом сервере. Стандартные средства 74 секунды бекап + 391 секунда сжатия в 7z = 465. Тот же эффект через PackDb — 446 секунд.
Варинат два на мощном сервере (база другая). 192 + 399 = 591 против 413.
Размер базы для примера: без сжатия 8.3Gb, сжатие средствами SQL — 1.9Gb, сжатие в 7z — 0.46Gb. Т.е. выигрыш на 1.5Gb для одной базы.
По поводу проблем с зипом — обнаружили, виновные будут наказаны. Есть проблемы со сжатием в zip при размерах базы более 2Gb (у зипа постоянно с этим проблемы лезут).
По цифрам.
Вариант раз на слабом сервере. Стандартные средства 74 секунды бекап + 391 секунда сжатия в 7z = 465. Тот же эффект через PackDb — 446 секунд.
Варинат два на мощном сервере (база другая). 192 + 399 = 591 против 413.
Размер базы для примера: без сжатия 8.3Gb, сжатие средствами SQL — 1.9Gb, сжатие в 7z — 0.46Gb. Т.е. выигрыш на 1.5Gb для одной базы.
По поводу проблем с зипом — обнаружили, виновные будут наказаны. Есть проблемы со сжатием в zip при размерах базы более 2Gb (у зипа постоянно с этим проблемы лезут).
это цифры для какой компрессии?
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?
проводили ли тесты на промышленных масштабах 200-300-500Гб? я бы попробовал на 300гб базе, но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(
в общем, идея интересная, но для меня выгода сомнительна, поскольку в приоритете время сохранения и еще важнее восстановления — если база допустим 300гб будет восстанавливаться не полчаса, а час-два, и мне это уже критично.
пожелания — добавить больше опций, как разные виды бэкапов (dif, log), так и например очень важный параметр COPY_ONLY (пригодилось бы если текущие бэкапы делать стандартно, а иногда запускать сжатые через утилиту для архива)
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?
проводили ли тесты на промышленных масштабах 200-300-500Гб? я бы попробовал на 300гб базе, но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(
в общем, идея интересная, но для меня выгода сомнительна, поскольку в приоритете время сохранения и еще важнее восстановления — если база допустим 300гб будет восстанавливаться не полчаса, а час-два, и мне это уже критично.
пожелания — добавить больше опций, как разные виды бэкапов (dif, log), так и например очень важный параметр COPY_ONLY (пригодилось бы если текущие бэкапы делать стандартно, а иногда запускать сжатые через утилиту для архива)
это цифры для какой компрессии?
normal
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?
Да с этим вроде нет проблем, это просто 7z такой медленный.
проводили ли тесты на промышленных масштабах 200-300-500Гб? но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(
Тут не должно быть никаких проблем, только долго (ну и обычный бекап долгий в данном случае). А с кластером — если на одном из узлов локально запустить?
Пожелания записали, будут ресурсы — сделаем.
В статье ни слова про differential backup и transaction log backup
Среди CLI свичей нет ничего, что намекало бы на восстановление из backup set-а с реплаем транзакшн лога к определенной точке.
Сжимать бэкапы файлами нет никакого смысла — если вы бесстрашные, то блочная дедубликация решает гораздо круче, а если аккуратные и консервативные — то ваш LTO5\6 накопитель уже умеет компрессить всё на лету, за него второй раз это делать нет никакого смысла. Бесстрашная стратегия круто работает на development средах, консервативная — в продакшне.
Ну и вместо сжатия файлов всегда можно использовать сжатие тома. Работает чуть похуже, зато 17 лет обратной совместимости.
Коль уж мы разобрались с бессмысленностью сжатия файла бэкапа (которая в общем-то есть в виде аттрибута в 2008м+ сервере больше девяти лет, правда только в Enterprise-версиях), то с остальным будет всё ещё проще. Права sysadmin вполне себе дают xp_cmdshell, и при аккуратном его использовании можно добиться того же эффекта (и даже сжимать бэкапный файл 7зипом после архивации, если вдруг прям очень сильно надо).
В общем, пока я был юн и неопытен — баловался скриптами для архивации СУБД. Как только пришло время точных сроков восстановления — сразу же symantec\ms dpm\yosemite — выбирайте по бюджету. Последняя, кстати, точно стоит дешевле месяца работы разработчика.
Среди CLI свичей нет ничего, что намекало бы на восстановление из backup set-а с реплаем транзакшн лога к определенной точке.
Сжимать бэкапы файлами нет никакого смысла — если вы бесстрашные, то блочная дедубликация решает гораздо круче, а если аккуратные и консервативные — то ваш LTO5\6 накопитель уже умеет компрессить всё на лету, за него второй раз это делать нет никакого смысла. Бесстрашная стратегия круто работает на development средах, консервативная — в продакшне.
Ну и вместо сжатия файлов всегда можно использовать сжатие тома. Работает чуть похуже, зато 17 лет обратной совместимости.
Коль уж мы разобрались с бессмысленностью сжатия файла бэкапа (которая в общем-то есть в виде аттрибута в 2008м+ сервере больше девяти лет, правда только в Enterprise-версиях), то с остальным будет всё ещё проще. Права sysadmin вполне себе дают xp_cmdshell, и при аккуратном его использовании можно добиться того же эффекта (и даже сжимать бэкапный файл 7зипом после архивации, если вдруг прям очень сильно надо).
В общем, пока я был юн и неопытен — баловался скриптами для архивации СУБД. Как только пришло время точных сроков восстановления — сразу же symantec\ms dpm\yosemite — выбирайте по бюджету. Последняя, кстати, точно стоит дешевле месяца работы разработчика.
Интересно было бы узнать, ради каких объемов данных это все затевалось и какова частота бэкапов?
Ребят, в bareos, имеется отличный плагин, который умеет сжатие, инкремент, и готовые тулзы для админства. :) Всё это free and opensource
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бекап баз данных через SQL VDI