ПО жизни всегда жал rar`ом, но вчера что-то решил сравнить...
Фулл бэкап базы 38 гиг rar`ом жмется в 1.8 гиг, SQL серваком жмется в 4.3 гиг. Так что какой-то алгоритм не очень у сервера, а rar по прежнему на высоте. Жмите rar`ом.

(0) Зачем?

щас такая цена 1руб/1мб что смешно экономить на объёме, время дороже - чтоб восстановить ещё час распаковывать? Жать архивы недельной давности раром тогда уж, свежие держать в первозданном виде

А уже сжатый sql-ем .bak, rar-ом в какой объем жмется?

(2) если у тебя 20-50 скульных баз, то экономия места в 3 раза все же нужна

1сд сжатый раром тоже кстати поменьше чем дт иногда получается

(4) Время всё равно дороже.

(4) Вопрос в том, что экономить - время или место

(7) а фигли время, если бэкап тихонько автоматически жмется, никому не мешает

(8) Угу, если запас мощности позволяет.

(8) Ты наверное удивишься, но во многих компаниях время простоя стоит больших денег. Поэтому время на восстановление из бэкапа более критично, чем размер архива.

(4) Купи за 100долларов 3ТБ и забудь про архиваторы еще на пару лет

а время сжатия сравнивал?
1. фулл бэкап (несжатый) + упаковка раром
2. фулл бэкап (сжатый)

правда у сжатого есть свой минус - MS SQL Server standart не может сжимать, но это полбеды, главное что он и восстанавливать из сжатого бэкапа не может.
Т.е. сделал бэкап сжатый на энтерпрпайз версии и капец - на стандарте не восстановишь.
Хотя может и есть обходные пути

(0) А чтобы восстановить бекап из полного+разностного на какой-то конкретный момент времени придётся распаковывать предварительно кучу (минимум два) файлов?

(12) Даже так
1. фулл бэкап несжатый
2. фул бэкап сжатый
Сжатый делается быстрее (правда при этом проц естся активнее, но не критично, т.к. фулл обычно делается во внерабочее время)
+ у меня была разниа примерно в 2 раза.
+ не требуется ставить вин рар (что там с лицензией при коммерческом применении?)

(13) Может. Но начиная с 2008 r2

да и к15 +скорость восстановления выше. Вельми.

(8) Время на разжатие зипа.

(17)сечас запущу гляну, архив весит 27 гигов

(0) в топку такие советы. Скульные базы должны бэкапится скулем.

(19) А кто-то предлагает делать архивы не скулем?

(0) заведи себе бложек что ли

(20) а - там про сжатие бэкапа. Такой фигней вообще не заморачивался.

(11) Когда сжатые рар-ом архивы весят десятки гигабайт, то 3 тб - это не панацея.

Замечал, что сжатие скулем в разы ускоряет бэкап, уменьшая нагрузку на диски, это тоже важный момент.

(11) У меня размер всех актуальных 8-ых баз (dt-ников) 7.5 гигов, т.е твои 3 Тв я за год забью, и это еще мне нужно место под 7-ные базы

(25) годовую историю архивации хранишь что ли?

(26) вобще то есть даже нормативы в законодательстве о сроке хранения информационных баз. Как на документы обычные бумажные некоторых категорий - 50 лет. На БД точно не помню)

(3) Плохо жмется, меньше чем изначальный. Размер словаря мал. что ли, у внутреннего алгоритма. или ещё что...
(4)+ У кого много баз, тот поймет
(12) Раром - дольше.
(21) Без... этих самых разберусь...

(27) песец. Но вообще хранение информационной базы и пачки бэкапов, имхо конечно, разные вещи.

(25) А тебе нужны _ежедневные_ бэкабы более чем годичной давности?