Який найефективніший спосіб стиснення та зберігання резервної копії SQL Server? [зачинено]

9

Я робив тестування різних методів компресії та зберігання резервних копій SQL Server (використовуючи видання SQL Server 2008 R2 Enterprise), і мені цікаво, який найефективніший алгоритм стиснення для довготривалого зберігання цих резервних копій за межами SQL алгоритми внутрішнього стиснення.

Мене не хвилюють фізичні накопичувачі або магнітофони чи щось подібне, я просто намагаюся перетворити наші 3 ТБ даних і файлів журналів у найменший єдиний файл, який я можу.

Так, наприклад, чи .zip чи .7z? Або всередині моєї бази даних є занадто багато змінних, щоб можна було точно оцінити, що буде найефективнішим, і мені просто потрібно зробити кілька тестів? Або внутрішнє стиснення SQL Server найкраще, що я отримаю?

sql-server-2008-r2 compression backup

— Шон Лонг
джерело

Фізичне зберігання - це рушійний фактор для цього, оскільки у нас на жорсткому диску недостатньо місця. Однак я хотів ухилятися від обговорення типу RAID, який я використовую, або відповідь "Просто отримайте більше блюд", оскільки це речі, над якими я вже працюю, але це довгострокові рішення.

— Шон Лонг

Це здається чимось, що ви можете перевірити, оскільки це буде значною мірою залежати від характеру ваших даних. Створіть резервну копію бази даних із стисненням, а потім спробуйте далі стиснути файл резервної копії за допомогою інших інструментів стиснення. Особисто я не можу собі уявити, що ви будете витрачати достатньо додаткового місця, щоб зробити його варто ускладнювати процес, і не забувайте, що більше стиснення = більше процесора, який іноді = більше часу. Тож якщо вам потрібна додаткова хвилина, щоб заощадити зайві 100 Мб дискового простору, чи варто цього коштувати, коли ви намагаєтесь відновити?

— Аарон Бертран

13

Я робив тестування різних методів компресії та зберігання резервних копій MS SQL (використовуючи MS SQL 2008 R2 Enterprise Edition), і мені цікаво, який найефективніший алгоритм стиснення для довготривалого зберігання цих резервних копій, поза межами SQL алгоритми внутрішнього стиснення.

Оскільки ви користуєтеся версією SQL 2008 R2 Enterprise, ви можете / потрібно скористатися

Стиснення даних - стиснення рядків та сторінок. на рівні даних
Стиснення резервного копіювання при знятті резервної копії, щоб мінімізувати дисковий слід резервного копіювання.
```
USE master;
GO
EXEC sp_configure 'backup compression default', '1';
RECONFIGURE WITH OVERRIDE;
```

Для стиснення резервного копіювання використовуються цикли процесора для стиснення даних до виходу з сервера, і саме тому в переважній більшості сценаріїв стислі резервні копії є швидшими, ніж нестиснені резервні копії.

Зауважте, що при використанні інструментів з відкритим кодом вам потрібно розпакувати файл резервної копії бази даних, перш ніж ви зможете самостійно запустити процес відновлення.

наприклад: Коли ви отримуєте резервну копію бази даних SQL 50 Гбіт, яка стискається до 5 ГБ. Щоб відновити цю базу даних, вам потрібно набагато більше дискового простору:

5 Гб для zip-файлу
50 Гб для резервного файлу
50 Gb для відновленої бази даних. (припустимо, що у базі даних немає порожнього місця)

Всього потрібно 105 Gb дискового простору.

Ви все ще можете використовувати засоби стиснення відкритих джерел, такі як gzip , 7Zip , bzip2 або QuickLZ після стиснення резервного копіювання, щоб отримати вигоду.

Крім того, подивіться MSSQL Compression Backup на кодоплексі.

Хороші посилання для статистики порівняння

— Кін Шах
джерело

3

Якщо ви стиснули резервні копії за допомогою компресії SQL, ви не зможете отримати велику компресію, якщо спробуєте скопіювати файл резервної копії / zzi / 7zip / rar.

— користувач1207758

8

Що стосується стиснення резервного копіювання, я (кілька років тому) здійснив порівняння параметрів стиснення резервного копіювання, передбачених резервною копією SQL Red Gate , LiteSpeed Quests для SQL Server і SQLSafe Idera , орієнтуючи ці три продукти. Відмінність типової резервної копії при максимальній компресії становила приблизно 5% -ний розкид між трьома за час, що взявся, і дещо ширший розкид щодо розміру резервного копіювання, при цьому Red Gate вийшов на перше місце (90% стиснення проти 80 та 85% для Idera & Квест, у такому порядку).

— Томас Раштон
джерело