Выбор архиватора для бэкапа логов

    Всем привет!


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


    Подразделение, в котором я работаю, занимается разработкой и сопровождением единой фронт офисной системы Банка. Я отвечаю за ее сопровождение, мониторинг и DevOps.


    Наша Система — это высоконагруженное приложение, ежедневно обслуживающее более 5 000 уникальных пользователей. На сегодняшний день — это «монолит» со всеми своими достоинствами и недостатками. Но сейчас активно идет процесс выноса функционала в микросервисы.


    Ежедневно наша система генерирует более 130 ГБ «сырых» логов и, несмотря на то, что мы используем ENG стек (Elasticsearch Nxlog Graylog), файловые логи содержат гораздо больше информации (например, stack trace ошибок), поэтому требуют архивирования и хранения.


    Так как место хранения ограничено, встаёт вопрос: «А какой архиватор лучше всего справится с этой задачей».


    Для решения этого вопроса я написал скрипт на языке PowerShell, который произвел анализ за меня.


    Задача скрипта вызвать архиваторы rar, 7z и zip с разными параметрами компрессии, посчитать скорость формирования архива, а также занимаемое место на диске.


    ArchSearch.ps1
    #Requires -Version 4.0
    
    # Очищаем экран, чтобы не мешало ничего лишнего
    Clear-Host
    
    # Переходим в каталог, где базируется исполняемый файл
    Set-Location $PSScriptRoot
    
    # Объявляем переменные, которые будем использовать в работе
    $Archive = "Archive"
    $ArchFileName = "ArchFileName"
    [array]$path = (Get-ChildItem '.\logs').DirectoryName|Select-Object -Unique
    
    # Для архивных файлов нам нужна папка-архив. Создаём ее, если она еще не создана.
    if ((Test-Path -Path ".\$Archive") -ne $true){
        New-Item -Path .\ -Name $Archive -ItemType Directory -Force
    } else {
        # Если папка существует - удаляем ее содержимое
        Get-ChildItem .\$Archive|Remove-Item -Recurse -Force
    }
    
    # Объявляем переменную для создания таблицы
    [array]$table=@()
    
    # Выполняем архивацию Rar
    #rar 
    #  m<0..5>       Set compression level (0-store...3-default...5-maximal)
    1..5|foreach{
    $CompressionLevel = $("-m" + $_)
    $mc = Measure-Command {cmd /c .\rar.exe a -ep1 -ed  $CompressionLevel -o+ -tsc .\$Archive\$($ArchFileName + $_) "$path"}
    [math]::Round(($mc.TotalMilliseconds), 0)
    $ArchFileNamePath = ".\$Archive\$($ArchFileName + $_ + ".rar")"
    $table += ""|Select-Object -Property @{name="ArchFileName"; expression={$ArchFileNamePath -split "\\"|Select-Object -Last 1}},`
    @{name="CompressionLevel"; expression={$CompressionLevel}},@{name="Extension"; expression={"rar"}},@{name="Size"; expression={(Get-ChildItem $ArchFileNamePath).Length}},`
    @{name="Time"; expression={[math]::Round(($mc.TotalMilliseconds), 0)}},`
    @{name="Size %"; expression={0}},@{name="Time %"; expression={0}},@{name="Result %"; expression={0}}
    }
    
    # Выполняем архивацию 7z
    #7z
    # -mx[N] : set compression level: -mx1 (fastest) ... -mx9 (ultra)
    #cmd /c "$env:ProgramFiles\7-Zip\7z.exe" a -mx="$MX" -mmt="$MMT" -t7z -ssw -spf $($ArchFileName + "Fastest") "$path"
    1..9|foreach{
    $CompressionLevel = $("-mx=" + $_)
    $mc = Measure-Command {cmd /c "$env:ProgramFiles\7-Zip\7z.exe" a $CompressionLevel -t7z -ssw -spf .\$Archive\$($ArchFileName + $_) $path} #-mmt="$MMT"
    [math]::Round(($mc.TotalMilliseconds), 0)
    $ArchFileNamePath = ".\$Archive\$($ArchFileName + $_ + ".7z")"
    $table += ""|Select-Object -Property @{name="ArchFileName"; expression={$ArchFileNamePath -split "\\"|Select-Object -Last 1}},`
    @{name="CompressionLevel"; expression={$CompressionLevel}},@{name="Extension"; expression={"7z"}},@{name="Size"; expression={(Get-ChildItem $ArchFileNamePath).Length}},`
    @{name="Time"; expression={[math]::Round(($mc.TotalMilliseconds), 0)}},`
    @{name="Size %"; expression={0}},@{name="Time %"; expression={0}},@{name="Result %"; expression={0}}
    }
    
    # Выполняем архивацию zip (Встроенная функция PS "Compress-Archive")
    #zip 
    1..2|foreach{
    
        Switch ($_){
    
            1{$CompressionLevel = "Fastest"}
    
            2{$CompressionLevel = "Optimal"}
    
        }
    $mc = Measure-Command {Compress-Archive -Path $path -DestinationPath .\$Archive\$($ArchFileName + $_) -CompressionLevel $CompressionLevel -Force}
    [math]::Round(($mc.TotalMilliseconds), 0)
    $ArchFileNamePath = ".\$Archive\$($ArchFileName + $_ + ".zip")"
    $table += ""|Select-Object -Property @{name="ArchFileName"; expression={$ArchFileNamePath -split "\\"|Select-Object -Last 1}},`
    @{name="CompressionLevel"; expression={$CompressionLevel}},@{name="Extension"; expression={"zip"}},@{name="Size"; expression={(Get-ChildItem $ArchFileNamePath).Length}},`
    @{name="Time"; expression={[math]::Round(($mc.TotalMilliseconds), 0)}},`
    @{name="Size %"; expression={0}},@{name="Time %"; expression={0}},@{name="Result %"; expression={0}}
    }
    
    # Выполняем сортировку по полю Size и берем первое значение [0] - это самый сжатый файл
    $Size = ($table|Sort-Object -Property Size)[0].Size / 100
    # Выполняем сортировку по полю Time и берем первое значение [0] - это самый быстро сжатый файл
    $Time = ($table|Sort-Object -Property Time)[0].Time / 100
    
    # Формируем итоговую таблицу
    $table|foreach {
    $_.time
    $_."Size %" = [math]::Round(($_.Size / $Size), 0)
    $_."Time %" = [math]::Round(($_.Time / $Time), 0)
        if ($_."Size %" -ge $_."Time %"){
            $_."Result %" = $_."Size %" - $_."Time %"
        } else {
            $_."Result %" = $_."Time %" - $_."Size %"
        }
    
    }
    
    # Выводим на экран таблицу с сортировкой по "Size %" - это самый сжатый файл
    $table|Sort-Object -Property "Size %","Result %"|Select-Object -First 1|Format-Table -AutoSize
    # Выводим на экран таблицу с сортировкой по "Result %" - оптимальный вариант между скоростью и занимаемым местом на диске
    $table|Sort-Object -Property "Result %","Size %","Time %"|Select-Object -First 1|Format-Table -AutoSize
    
    $table|Sort-Object -Property "Size %","Result %"|Select-Object -First 1|Format-Table -AutoSize
    $table|Sort-Object -Property "Result %","Size %","Time %"|Select-Object -First 1|Format-Table -AutoSize
    
    # Работа сделана! Удаляем созданные архивы, чтобы не занимали место
    Get-ChildItem .\$Archive|Remove-Item -Force

    Подготовительные работы:


    # Запрещаем запускать скрипт, если версия PowerShell меньше 4.0 ($PSVersionTable):
    #Requires -Version 4.0
    
    # Очищаем экран, чтобы не мешало ничего лишнего
    Clear-Host
    
    # Переходим в каталог, где базируется исполняемый файл (возможность использовать путь .\)
    Set-Location $PSScriptRoot

    # Объявляем переменные, которые будем использовать в работе
    $Archive = "Archive"
    $ArchFileName = "ArchFileName"
    [array]$path = (Get-ChildItem '.\logs').DirectoryName|Select-Object -Unique
    
    # Для архивных файлов нам нужна папка-архив. Создаём ее, если она еще не создана
    if ((Test-Path -Path ".\$Archive") -ne $true){
        New-Item -Path .\ -Name $Archive -ItemType Directory -Force
    } else {
        # Если папка существует, то удаляем ее содержимое
        Get-ChildItem .\$Archive|Remove-Item -Recurse -Force
    }
    
    # Объявляем переменную для создания таблицы
    [array]$table=@()

    Разбираем подробнее


    # Формируем массив данных от 1 до 5 и передаем через конвейер в цикл foreach
    1..5|foreach{

    # Передаем в переменную $CompressionLevel значение от 1 до 5($_), это необходимо для формирования уровня компрессии
    $CompressionLevel = $("-m" + $_)

    # Командлет Measure-Command позволяет посчитать время выполнения команды, заключенной в {}
    $mc = Measure-Command {cmd /c .\rar.exe a -ep1 -ed  $CompressionLevel -o+ -tsc .\$Archive\$($ArchFileName + $_) "$path"}

    # Выводим время выполнения запроса на экран
    [math]::Round(($mc.TotalMilliseconds), 0)
    # Формируем переменную вида $ArchFileName + $_ + ".rar": Archive1.rar
    $ArchFileNamePath = ".\$Archive\$($ArchFileName + $_ + ".rar")"
    # Формируем таблицу $table построчно(+=) добавляя данные
    $table += ""|Select-Object -Property @{name="ArchFileName"; expression={$ArchFileNamePath -split "\\"|Select-Object -Last 1}},`
    @{name="CompressionLevel"; expression={$CompressionLevel}},@{name="Extension"; expression={"rar"}},@{name="Size"; expression={(Get-ChildItem $ArchFileNamePath).Length}},`
    @{name="SizeAVD"; expression={0}},@{name="Time"; expression={[math]::Round(($mc.TotalMilliseconds), 0)}},`
    @{name="Size %"; expression={0}},@{name="Time %"; expression={0}},@{name="Result %"; expression={0}}
    }

    # Выполняем сортировку по полю Size и берем первое значение [0] - это самый сжатый файл
    $Size = ($table|Sort-Object -Property Size)[0].Size / 100
    # Выполняем сортировку по полю Time и берем первое значение [0] - это самый быстро сжатый файл
    $Time = ($table|Sort-Object -Property Time)[0].Time / 100
    
    # Формируем итоговую таблицу
    $table|foreach {
    $_.time
    $_."Size %" = [math]::Round(($_.Size / $Size), 0)
    $_."Time %" = [math]::Round(($_.Time / $Time), 0)
        if ($_."Size %" -ge $_."Time %"){
            $_."Result %" = $_."Size %" - $_."Time %"
        } else {
            $_."Result %" = $_."Time %" - $_."Size %"
        }
    
    }
    
    # Выводим на экран таблицу с сортировкой по "Size %" - это самый сжатый файл
    $table|Sort-Object -Property "Size %","Result %"|Select-Object -First 1|Format-Table -AutoSize
    # Выводим на экран таблицу с сортировкой по "Result %" - оптимальный вариант между скоростью и занимаемым местом на диске
    $table|Sort-Object -Property "Result %","Size %","Time %"|Select-Object -First 1|Format-Table -AutoSize
    
    # Работа сделана! Удаляем созданные архивы, чтобы не занимали место.
    Get-ChildItem .\$Archive|Remove-Item -Force

    $table|Sort-Object -Property "Size %","Result %"|Format-Table -AutoSize

    ArchFileName Compression Level Extension Size Time Size % Time % Result %
    ArchFileName8.7z -mx=8 7z 26511520 62404 100 1674 1574
    ArchFileName9.7z -mx=9 7z 26511520 64614 100 1733 1633
    ArchFileName7.7z -mx=7 7z 28948176 52832 109 1417 1308
    ArchFileName6.7z -mx=6 7z 30051742 37339 113 1002 889
    ArchFileName5.7z -mx=5 7z 31239355 35169 118 943 825
    ArchFileName4.rar -m4 rar 33514693 11426 126 306 180
    ArchFileName5.rar -m5 rar 33465152 12894 126 346 220
    ArchFileName3.rar -m3 rar 33698079 9835 127 264 137
    ArchFileName2.rar -m2 rar 34399885 8352 130 224 94
    ArchFileName4.7z -mx=4 7z 38926348 6470 147 174 27
    ArchFileName3.7z -mx=3 7z 44545819 5889 168 158 10
    ArchFileName2.7z -mx=2 7z 51690114 4754 195 128 67
    ArchFileName1.rar -m1 rar 53605833 4600 202 123 79
    ArchFileName1.7z -mx=1 7z 57472172 3728 217 100 117
    ArchFileName2.zip Optimal zip 65733242 14025 248 376 128
    ArchFileName1.zip Fastest zip 81556824 9031 308 242 66

    $table|Sort-Object -Property "Result %","Size %","Time %"|Format-Table -AutoSize

    ArchFileName Compression Level Extension Size Time Size % Time % Result %
    ArchFileName3.7z -mx=3 7z 44545819 5889 168 158 10
    ArchFileName4.7z -mx=4 7z 38926348 6470 147 174 27
    ArchFileName1.zip Fastest zip 81556824 9031 308 242 66
    ArchFileName2.7z -mx=2 7z 51690114 4754 195 128 67
    ArchFileName1.rar -m1 rar 53605833 4600 202 123 79
    ArchFileName2.rar -m2 rar 34399885 8352 130 224 94
    ArchFileName1.7z -mx=1 7z 57472172 3728 217 100 117
    ArchFileName2.zip Optimal zip 65733242 14025 248 376 128
    ArchFileName3.rar -m3 rar 33698079 9835 127 264 137
    ArchFileName4.rar -m4 rar 33514693 11426 126 306 180
    ArchFileName5.rar -m5 rar 33465152 12894 126 346 220
    ArchFileName5.7z -mx=5 7z 31239355 35169 118 943 825
    ArchFileName6.7z -mx=6 7z 30051742 37339 113 1002 889
    ArchFileName7.7z -mx=7 7z 28948176 52832 109 1417 1308
    ArchFileName8.7z -mx=8 7z 26511520 62404 100 1674 1574
    ArchFileName9.7z -mx=9 7z 26511520 64614 100 1733 1633

    # Работа сделана! Удаляем созданные архивы, чтобы не занимали место.
    Get-ChildItem .\$Archive|Remove-Item -Force

    Итог:
    Самым экономичным по месту на диске оказался 7z со степенью сжатия -mx=8 и -mx=9



    Самым быстрым по времени создания архива оказался 7z со степенью сжатия -mx=1



    Самым оптимальным по скорости и занимаемому месту оказался 7z со степенью сжатия -mx=3



    Мы выбираем 7z со степенью сжатия -mx=8, так как по размеру архива он равен -mx 9, но при этом работает чуть быстрее.


    Отлично, архиватор и степень сжатия выбраны, теперь давайте заархивируем логи!


    Нам нужно решить следующие задачи:


    1. Избегать высокой нагрузки на сервер во время работы.
    2. Обрабатывать все папки с вложенной папкой Logs.
    3. Удалять архивы старше 30 дней (чтобы не заканчивалось место на диске).
    4. Создавать архивы по дням в зависимости от времени изменения файлов.

    ArchLogs.ps1
    #Requires -Version 4.0
    
    # Добавляем в планировщик заданий если необходимо задачу архивации логов
    #SCHTASKS /Create /SC DAILY /ST 22:00 /TN ArchLogs /TR "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\Scripts\ArchLogs.ps1" /RU "NT AUTHORITY\NETWORKSERVICE" /F /RL HIGHEST
    
    # Очищаем экран, чтобы не мешало ничего лишнего
    Clear-Host
    
    # Переходим в каталог, где базируется исполняемый файл
    Set-Location $PSScriptRoot
    
    # Описываем функцию получения значения потоков в зависимости от количества ядер процессора.  
    # Условие 1
    Function Set-MMTCore {
    
    $Core = (Get-WmiObject –class Win32_processor|Measure-Object NumberOfLogicalProcessors -sum).Sum / 2
    $CoreTMP = $Core / 4
    IF ($Core -lt 4)
        {
        $Core = $Core -1
        }
        Else
        {
        $Core = $Core - $CoreTMP
        }
    [math]::Round($Core)
    }
    
    # Задаем степень сжатия
    $MX = 8
    # Получаем количество потоков работы
    $MMT = Set-MMTCore
    
    # Объявляем переменные, которые будем использовать в работе
    $SearchFolder = "C:\inetpub"
    # Получаем объекты из папки $SearchFolder
    $InetpubFolder = Get-ChildItem $SearchFolder
    # Ищем папки с подпапкой Logs
    # Условие 2
    $LogsFolder = $InetpubFolder|foreach {Get-ChildItem $_.Fullname|Where-Object{$_.PSIsContainer -eq $true}|Where-Object{$_.name -eq "logs"}}
    
    # Объявляем переменные, которые будем использовать в работе
    $Archive = "Archive"
    $ArchiveFile = "ArchFiles.txt"
    
    # Перебираем по одной паке из $LogsFolder передавая в $LogsFolderName полный путь
    foreach($LogsFolderName in $LogsFolder.Fullname){
    $LogsFolderName
    # Создаем папку $Archive, если она не была создана ранее
    IF ((Test-Path -Path "$LogsFolderName\$Archive") -ne $true){New-Item -Path $LogsFolderName -Name $Archive -ItemType Directory -Force}
    # Удаляем файлы старше 30 дней
    # Условие 3
    Get-ChildItem "$LogsFolderName\$Archive"|Where-Object {$_.LastWriteTime -le (Get-Date).AddDays(-30)}| Remove-Item -Force
    # Получаем файлы для архивирования
    [Array]$ArchiveItems = Get-ChildItem -Path $LogsFolderName -Exclude $Archive
        # Если файлы есть, продолжаем. В другом случае - выходим
        IF ($ArchiveItems.Count -ne "0"){
        # Нас интересуют файлы изменённые не сегодня
        $AllLogsFiles = Get-ChildItem $ArchiveItems -Recurse <#-Filter *.log#>|Where-Object {$_.LastWriteTime -lt (Get-Date).Date}
        # Получаем дату изменения файлов
        # Условие 4
        $AllData = ($AllLogsFiles|Sort-Object -Property LastWriteTime).LastWriteTime.Date|Select-Object -Unique
        $AllData
            foreach ($Data in $AllData){
                IF ($ArchiveItems.Count -ne "0"){
                # Формируем список файлов для архивации за определенную дату
                ($AllLogsFiles|Where-Object {$_.LastWriteTime -lt (Get-Date).Date}|Where-Object {$_.LastWriteTime -ge (Get-Date $Data) -and $_.LastWriteTime -lt (Get-Date $Data).AddDays(1)}).FullName|Out-File .\$ArchiveFile -Force -Encoding default
                Write-Host "==="
                $Data
                Write-Host "==="
                    # Если файлы существуют архивируем их
                    IF ($(Get-Content .\ArchFiles.txt -Encoding default) -ne $null){
                    $ArchiveFileName =$(($LogsFolderName.Remove($LogsFolderName.LastIndexOf("\"))) -split "\\"|Select-Object -Last 1) + "_" + $(Get-Date $Data -Format dd-MM-yyyy)
                    cmd /c "$env:ProgramFiles\7-Zip\7z.exe" a -mx="$MX" -mmt="$MMT" -t7z -ssw -sdel "$LogsFolderName\$Archive\$ArchiveFileName" "@$ArchiveFile"
                    # Удаляем файл со списокм файлов для архивирования
                    IF(Test-Path ".\$ArchiveFile"){Remove-Item ".\$ArchiveFile" -Force}
                    # Удаляем пустые папки внутри папки Logs
                    $LogsFolderName|foreach {Get-ChildItem $_|Where-Object {(Get-ChildItem -Path $_.FullName) -eq $null}|Remove-Item -Force}
                    }
                }
            }
        }
    }

    Здесь я не буду расписывать каждую строчку скрипта(описано в комментариях), а остановлюсь лишь на функции Set-MMTCore, которая позволяет нам вычислить количество потоков для 7z, чтобы не грузить процессор на нашем сервере:


    Function Set-MMTCore {
    # Получаем сумму ядер процессора и делим на 2
    $Core = (Get-WmiObject –class Win32_processor|Measure-Object NumberOfLogicalProcessors -sum).Sum / 2
    # Получившееся значение делим еще на 4
    $CoreTMP = $Core / 4
    IF ($Core -lt 4)
        {
        $Core = $Core -1
        }
        Else
        {
        $Core = $Core - $CoreTMP
        }
    #Округляем значение до целого
    [math]::Round($Core)
    }

    Без использования функции Set-MMTCore

    Видно, что CPU упирается в 100%. Это значит, что мы неизбежно вызовем проблемы на сервере, а также получим алерт от системы мониторинга.



    При использовании функции Set-MMTCore

    Видно, что CPU равен 30-35%. Это значит, использование функции Set-MMTCore позволяет архивировать файлы без влияния на работу сервера.



    Итог работы скрипта архивации:


    Папка до архивации:


    Папка после архивации:


    Файлы созданные в процессе архивации:


    Файлы в архиве:


    ООО «Хоум Кредит Энд Финанс Банк»
    Company

    Comments 48

      0

      5000 пользователей в сутки? Может 5 млн?

        0
        Пять миллионов в сутки для какого-то ООО «Хоум Кредит Энд Финанс Банк»?
        Просто у всех разные представления о высокой нагрузке ;)
          0
          У нас приложение для сотрудников, это около 2500 одновременно работающих операторов за 5 мин
          +1
          А с zstd не экспериментировали? Для 7-zip есть форк с его поддержкой или же плагин для официальной версии.
            0
            Нет я выбирал из масмаркета, чтобы бала возможность быстро разархивировать в случае необходимости на любом ПК.
              0

              Какой резон подобной манипуляции?
              Распаковывать сотни гигов продакшн логов на любом ПК — выглядит очень странно со многих сторон.
              Например, безопасности.

                0
                На любой ПК — имеется ввиду ПК администраторов приложения, в сырых логах есть StackTrace ошибок которые мы не пишем в ElasticSearch чтобы экономить место.
              0

              zstd не самый лучший выбор, если интересует скорость компрессии, например

                0

                вы серьёзно? скорость компрессии как раз сильная сторона zstd (например, на дефолтном уровне коэффициент сжатия примерно как у deflate, но сжатие в разы быстрее)

              0
              ZStandard ещё попробуйте
                +2

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

                  0

                  Аномалии можно не упаковывать, это позволит их находить вовремя.

                  0
                  Думаю, что это довольно сильная работа… но хотелось бы написать несколько о другом. О структуре расходов в IT.
                  Работал я в одной компании не очень давно. 200Gb в день — это только с Firebase Analytics приходило… В общем всё жило в BigQuery. Ничего (очень сложного) писать было не нужно. Дешевле использовать что предлагают по умолчанию, чем писать (а главное поддерживать) специализированные решения. Главные расходы — люди.
                    0
                    Сегодня мы осуществляем поддержку приложения в троем, а 8 лет назад нас было 12 человек! При этом тогда это был только фрон-офис и 4 тестовые среды, а сейчас 2 фронт-офиса куча микросервисов и более 20 тестовых сред. Все это благодаря автоматизации нашей работы.
                    Согласен, что поддерживать специализированные решения не простая задача, но компьютер способен работать в 1000 раз эффективнее человека, надо только научить. Поэтому мы стараемся автоматизировать все к чему прикасаемся. :-)
                    Это позволяет нам постоянно развиваться, а также оставаться эффективными не увеличивая расходы на людей.
                      0
                      Один уехал в отпуск, второй заболел, третий спит. Сервис упал по непонятной причине. Ваши действия?
                      Ещё был случай, когда один посреди пустыни, а двое отравились обедом, и как всегда именно в этот момент…
                        0
                        Да, такие ситуации могут случиться, но я глубоко убежден, что самая устойчивая в мире фигура треугольник. Поэтому мы ориентируемся на минимальное необходимое число 3, это касается как людей в командах так и конфигурации серверов.
                        Ситуации «Сервис упал по непонятной причине» мы стараемся не допускать, для этого внедряем всесторонний мониторинг, следим за показателями SLO/SLA, проводим нагрузочное, авто и регрессионное тестирование, выполняем канареечные деплои, а также автоматизируем ручные процессы администраторов. Ведь как известно самые частые действия приводящие к ошибке, это человеческий фактор.
                    +2

                    "rar, 7z и zip"?
                    Многопоточный pigz должен их всех уделать.
                    Попробуйте и покажите результаты...

                      0
                      Судя по статье, автор тестировал архиваторы/упаковщики под винду. С pigz надо использовать tar, а это для винды не совсем нативный сценарий. Ну и тогда уж сравнивать надо с zstd (zstdmt), а не pigz ибо последний в большинстве тестов проигрывает как по скорости, так и по степени сжатия
                        0
                        Спасибо попробуем.
                        +2

                        В 7-Zip поддерживается несколько алгоритмов сжатия (напр. PPMd), для логов имеет смысл попробовать и альтернативные алгоритмы.

                          –2
                          я может выскажу непопулярную мысль, но бэкап должен быть таким, чтобы можно было восстановиться в случае любого форсмажора. Чтобы когда сисадмин был пьян, и в наличии только новенький слепой стажер; когда все сервера сгорели, и доступен только 386 из музея, когда ядерный взрыв сжег сжег к чертям сервер активации виндоус, чтобы даже тогда бэкап разворачивался без проблем.
                          Я за tgz короче. Потомки вам скажут спасибо.
                            0

                            Если я правильно понял пост, то в нем не идёт речи про бекап

                            0
                            Попробуйте Winzip и его формат zipx. У меня на логах получалось заметно лучше сжатие, чем 7z и rar. На моих данных логи ужимаются в 15-17 раз (размер данных в архиве 17-30 ГБ до сжатия), winrar и 7zip на максималках давали сжатие 10-11 раз. При этом 7zip на максималке сильно медленнее winzip.
                              +1
                              А почему не попробовали xz?
                              по сжатию он показывает одни из наилучших результатов, особоенно для повторяющегося текстового контента типа логов.
                                0

                                Если там NTFS, можно поставить папке с логами атрибут сжатия. Бекапу это не поможет, но логов влезет больше и делается просто.

                                  0

                                  Я давно от этого отказался, так как есть существенное влияние на cpu, для файл сервера это применимо, но для сервера приложений нет.

                                    0
                                    Если можно, поделитесь оценкой влияния на cpu NTFS-сжатия.
                                      0
                                      Сейчас уже не воспроизведу, есть неплохая статья: www.thg.ru/storage/ntfs_osvobozhdaem_mesto_na_ssd/print.html.
                                      Недостатки: согласно Microsoft, NTFS-сжатие сильно нагружает CPU, и не рекомендуется для использования в серверах, содержащих большие тома для чтения и записи. Есть запреты даже для домашнего использования. Сжатие стоит использовать для папок с относительно редкой записью и чтением. Что ещё более важно, не сжимайте системную папку Windows. Также, в теории, операции копирования должны происходить медленнее, потому как файловая система сначала распаковывает нужный файл, копирует или перемещает его и затем снова сжимает. Если послать такие файлы по сети, они тоже сначала распакуются и как следствие не сэкономят трафик.
                                        0
                                        Спасибо. Теорию я знаю, думал у вас есть результаты замеров.
                                  –1

                                  Если эти логи архиважны то по моему скромному мнению ни о какой архивации бэкапов логов речь идти не может. Правильнее увеличить и задублировать в нужное кол-во раз место для этих бэкапов. Да — стоит денег, но не будет никаких проблем (возможность которых навскидку вижу аж несколько и случится они могут в самый неподходящий момент)

                                    0

                                    Сырые логи не так важны как обработанные, но хранить их надо потому, что в 5% случаев мы к ним обращаемся, в других случаях мы используем собственную систему обработки и хранения логов LV, а также ENG стек(быстрый поиск, аналитика, графики в Grafana)

                                  • UFO just landed and posted this here
                                      0

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

                                        –2

                                        Максимально простое решение в этом случае. +2 ширпотребных накопителя по 8 тб. Ваши логи за 30 дней в несжатом виде занимают 4тб, в сжатом пусть 2 — все равно под них нужно выделить место. Да, это +$600, но никаких костылей с упаковкой-распаковкой, отличная скорость доступа и никакой нагрузки на процессор. Эксперименты с выбором правильного архиватора обошлись конторе немного дешевле ;)

                                          0
                                          Ваши логи за 30 дней в несжатом виде занимают 4тб, в сжатом пусть 2

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

                                        • UFO just landed and posted this here
                                          0
                                          Дедупликация скорее всего мало что даст. Так как в логах как минимум постоянно вставляется дата и время события в каждую строку, и сами строки обычно меньше размера блока, который используется для дедупликации.
                                          0
                                          Странно что никто не спросил. Не пробовали дедупликацию? Под виндой очень даже хорошо работает и очень хорошо экономит место на диске. Особенно если для последующего анализа их надо распаковать, а тут просто задедуплицированны и можно спокойно смотреть. Или я не так понял посыл статьи для решения задач?
                                          • UFO just landed and posted this here
                                            0

                                            Если вам действительно нужен рационально выверенный баланс между скоростью сжатия/разжатия и уровнем компрессии, то нужно использовать современные алгоритмы. Соответственно см https://github.com/mcmilk/7-Zip-zstd (там несколько алгоритмов, не только zstd).

                                              0

                                              image

                                              0
                                              Интересные тесты со странной интерпретацией. Вот нужное место:
                                              ArchFileName5.7z -mx=5 7z 31239355 35169 118 943 825
                                              ArchFileName4.rar -m4 rar 33514693 11426 126 306 180

                                              Тут rar обеспечивает близкий результат компресии за время в 3 раза меньшее, чем 7z. И этот качественный скачок виден даже при беглом взгляде на график.
                                              Предпочитая ему mx8, вы покупаете крохи в виде 26% относительного сжатия за умопомрачительные 1368% дополнительного времени.
                                              Крохи — это не иносказательно. Хранение 130 ГБ — это грубо 250 рублей. Для верности представим, что вы так дорожите логами, что кладете их на RAID1. За 500 рублей. Месячный запас RAID1 для ваших ничем не жатых логов — 15000 руб.
                                              То есть, ваша задача — не экономия пары банковских серебрянников, а возможность это добро передавать по сети. И для этого время важнее размера. Пока вы «кипятите», менее жатый архив уже можно было передать по сети на другое хранилище, в другой регион, облако и т.д.

                                              Так, например, сливая файлы с vds, я сжимаю их «на лету» в gzip-2. Если поставить gzip-3 — архив будет немного меньше, но получу я файлы гораздо позже.
                                                +1

                                                Хм, только сейчас обратил внимание на то, как вычисляется "Result %".
                                                Некий "шарообразный в вакууме" оптимум точно найден, осталось понять для чего он оптимален )


                                                Их линейка кривовата относительно здравого смысла. Оптимум выбирается видимо "по-банковски", как лучшая сделка из совершенных по покупке сжатия за время. Но ошибка в том, что в "пропорцию" на равных попадают все варианты, включая самые долгие, хотя жмут лишь чуточку лучше. Соответственно, время обесценивается относительно степени сжатия.


                                                Нельзя сказать что это как-то совсем не правильно, критерии могут быть разные.
                                                Но один из вариантов (с точки зрения оптимизации) — нулевое время без сжатия, и он линейку ломает.
                                                А если добавить еще несколько экстремально долгих вариантов, то перекос будет еще больше.

                                                  0
                                                  Меня тоже сначала дизайн исследования привлек. Очень необычно, смело, без прелюдий. Относительное сравнение сразу бабашится в относительных величинах, без конвертации абсолютных значений. Такая жесткая военная логика: «Возьмем n танков. Нет, n мало. Возьмем k!».

                                                  Сама задача, конечно, не имеет практической ценности, так как узкое место всех этих самопальных скриптовых бэкап-экзерсисов — контроль ошибок и мониторинг. Надо проверять дожалось ли все корректно в убер-режиме, не было ли сбоя питания, не заполнен ли диск, запущены ли службы и так далее. Т.е., изобретать все, что испокон веков есть в стандартных открытых системах типа Bacula/Bareos.
                                                  0
                                                  Согласен rar -m4 тоже не плохой вариант.
                                                  0
                                                  Меня как будто откинуло на 20-30 лет назад. Arctest, fido ru.compress… Спасибо за ностальгию, конечно, но в 2020 реальность такова, что можно считать все архиваторы примерно одинаковыми, выбрать дефолтный zip и желаемую скорость.

                                                  UPD. Прикиньте, arctest ещё жив. Правда не обновлялся лет 20.
                                                    0
                                                    выбрать дефолтный zip и желаемую скорость

                                                    Ну да конечно, особенно если Вам нужно архивировать логи, которых с десяток гигов каждый день. Тут же уже речь не о том, чтобы игрушку на меньше дискет записать. Речь о месте для бэкапа, за которое нужно платить деньги.
                                                    Вот для примера, сжал несколько лог-файлов, на максималках каждого архиватора.

                                                    Без сжатия 3758 МБ
                                                    zip 618 МБ
                                                    rar 532 МБ
                                                    7z 426 МБ
                                                    zipx 345 МБ


                                                    При этом zipx сжимал 5 минут, а 7z — 25 минут, zip (с помощью 7-zip) — 20, rar — 12.

                                                    Т.е. простой выбор zipx вместо zip, получаем почти в 2 раза меньше платить бабла за хранилище, и в 4 раза меньше нагрузка на проц, вот и жмите теперь всё в zip. Причем когда логов за большее количество дней, то сжатие zipx еще лучше. В то время, как zip не поддерживает общий словарь.
                                                      0

                                                      Спасибо попробую zipx

                                                  Only users with full accounts can post comments. Log in, please.