Резервные копии SQL в сжатой папке

Question

Мы ищем бесплатное решение для сжатия наших резервных копий SQL Server для SQL Server 2005. Мне известно о бесплатной редакции SQL Safe, но мне было интересно, что другие думают о хранении файлов резервных копий в сжатых папках для достижения желаемого результата. Это позволило бы нам использовать собственные задачи резервного копирования SQL и собственное сжатие Windows, что устраняет необходимость в сторонних продуктах.

В прошлом я ни для чего не использовал сжатые папки. Это жизнеспособная идея? Есть ли какие-либо предполагаемые проблемы с целостностью резервных копий в сжатой папке?

Answer 1

Я являюсь автором проекта с открытым исходным кодом (GPL v3), который делает то, что вы ищете. Это инструмент командной строки (для планирования в запланированных задачах в Windows), который создает резервные копии в gzip, zip (в частности, в zip64 из-за ограничения в 4 ГБ с обычными zip-файлами) или bzip2. Вы можете использовать инструмент для восстановления непосредственно из сжатых файлов или распаковать сжатые файлы (которые являются стандартными * .bak файлами), а затем использовать графический интерфейс SQL Server для восстановления.

Это называется SQL Server Compressed Backup, находится здесь: http://sourceforge.net/projects/mssqlcompressed/

Пример команды будет:

msbp.exe backup "db(database=model)" "zip64" "local(path=c:\model.full.bak.zip)"

Answer 2

Быстрый совет от Google: резервное копирование в ntfs-сжатую папку . Кажется, что размер базы данных может создавать проблемы.

Что касается бесплатных решений, то вы можете запустить 7zip в запланированном пакете после резервного копирования, если правильно обрабатывать большие файлы. В любом случае вы должны переместить резервные копии с рабочего сервера:)

Answer 3

Хотя я не рекомендую выполнять резервное копирование непосредственно в сжатую папку, вы, безусловно, можете сделать резервную копию в обычную папку, а затем использовать сценарий PowerShell для сжатия каждого файла по отдельности, когда сервер не слишком занят. Вот фрагмент того, что я использую. Он в основном повторяется через каталог резервного копирования, сжимая каждый файл с использованием сжатия NTFS, до определенного размера. Это не самое лучшее решение; Мое предпочтительное решение будет использовать сжатие резервных копий SQL 2008/2012 вместо этого при моем обновлении.

$max_compressible_size = 10*1024*1024*1024 #10 gigs 

$files = Get-ChildItem -recurse | where {$_.Extension -match "(trn)|(diff)|(bak)"}

foreach ($file in $files) {    
    $attr = (Get-ItemProperty $file.fullname).Attributes

    if ($attr.ToString() -notmatch ".*Compressed.*" -and $file.Length -le $max_compressible_size) {
        write-output $file.FullName
        compact /C $file.FullName
    }
}

Answer 4

У нас около 100 баз данных на серверах у нашего провайдера

Интернет-провайдер имеет всеобъемлющее резервное копирование на ленту, но ему требуется много времени для восстановления чего-либо ... поэтому нам необходимо хранить резервные копии в оперативном режиме в течение разумного периода времени, чтобы мы могли в первую очередь восстановить их.

Мы производим полное резервное копирование один раз в неделю и разностное резервное копирование ежедневно. Мы храним полные резервные копии в течение месяца и разностные резервные копии в течение семи дней. Мы создаем резервные копии TLog каждые 10 минут, но храним их (онлайн) только два дня.

Таким образом, мы можем восстановиться до момента времени за предыдущие 2 дня, до «полуночи» за последние 7 дней и до «воскресенья до» за последние 4 недели.

Использование разностных резервных копий уменьшает общий размер наших резервных копий и позволяет нам держать больше «прошедшего времени» в сети.

Все резервные копии хранятся в сжатых папках NTFS. У нас никогда не было проблем, но я не думаю, что у нас есть какие-либо базы данных> 30 ГБ на этих «общих серверах БД»

Во время обслуживания базы данных (дефрагментация индекса и т. Д.) Мы увеличиваем частоту резервного копирования TLog до каждой минуты. Мы обнаружили, что единственное, что расширило размер БД, - это обслуживание БД, поэтому мы смогли уменьшить операционный размер наших баз данных и, в свою очередь, освободить место на диске для большего количества резервных копий. (Резервные копии обычно создаются на разных дисках в MDF или LDF, но пакетные операции копируют старые, устаревшие файлы резервных копий на диски, содержащие MDF / LDF, просто чтобы мы могли держать их «в оперативном режиме»)

P.S. SQL 2008 имеет встроенную функцию сжатого резервного копирования на случай, если вы планируете обновить

Answer 5

Я использую Syncback Freeware для автоматического копирования и сжатия файлов в другую папку. Таким образом вы экономите тонны пространства. Я делал это в течение нескольких лет, и это сработало отлично.