компьютеры

Хозяйке на заметку

Я часто бекаплю фрюниксы и линупсы встроенными средствами с компрессией. В частности, вот так можно сделать посекторный бекап диска:

dd bs=32M if=/dev/sda | gzip -c -9 | dd bs=512k of=image.gz

То-есть, посекторно читаем диск /dev/sda, сжимаем его в gzip с максимальным сжатием и записываем в файл image.gz. Размеры блока (параметр bs для dd) подбирается экспериментально. Тут получается неплохо.

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

Как? Очень просто. Надо использовать не gzip, а pigz (произносится "пигзи"). Это тот же самый gzip, но распараллеленный. Производительность растёт -- просто обалдеть, как. Обычный gzip нагружал машину максимум на 12% (восьмиядерный процессор, 1/8). pigz легко фигачит на все 60%.

То-есть, вот так:

dd bs=32M if=/dev/sda | pigz -c -9 | dd bs=512k of=image.gz

Или, в обратном порядке, развернуть образ на диск:

dd bs=512k if=image.gz | pigz -d | dd bs=128M of=/dev/sda

Данный способ я использую для клонирования дисков рабочих станций. Так как ко всему этому можно подцепить netcat, диски можно клонировать прямо по сети.

Так вот, при использовании gzip я пишу на диск со скоростью 170 мегабайт в секунду. При использовании pigz -- 440 мегабайт в секунду. Разница, мягко говоря, есть.

Способ применим, разумеется, ко всем юниксовым средствам бекапа -- хотя бы к тому же mysqldump.
Ага, я этими свинками базы данных пакую, а то жуть чё творится с процем во время обычного gz.
Попробовал. Результаты неоднозначные, надо тестировать ещё.

# date ; pbzip2 -c -9 testfile.dat > testfile.bz2 ; date
Wed Jan 27 21:04:38 EST 2016
Wed Jan 27 21:05:43 EST 2016

pbzip2 потратил на сжатие файла 1 минуту и 5 секунд.

# date ; pigz -c -9 testfile.dat > testfile.gz ; date Wed Jan 27 21:06:02 EST 2016
Wed Jan 27 21:06:21 EST 2016

pigz потратил на сжатие того же файла 19 секунд (т.е. в три с гаком раза быстрее).

Может быть, pbzip2 лучше сжимает?

# ls -l testfile*
-rw-r--r--. 1 root root 2111105581 Jan 27 21:05 testfile.bz2
-rw-r--r--. 1 root root 2194750829 Jan 27 21:01 testfile.dat
-rw-r--r--. 1 root root 2060531064 Jan 27 21:06 testfile.gz

Нет, нифига не лучше.

Ну хорошо, может, это файл такой был нехороший.

Возьмём одни нули.

# dd count=2 bs=1024M if=/dev/zero of=testfile.dat

И дадим те же команды

# date ; pbzip2 -c -9 testfile.dat > testfile.bz2 ; date
Wed Jan 27 21:14:07 EST 2016
Wed Jan 27 21:14:12 EST 2016

5 секунд на сжатие.

# date ; pigz -c -9 testfile.dat > testfile.gz ; date
Wed Jan 27 21:14:22 EST 2016
Wed Jan 27 21:14:26 EST 2016

Чуть побыстрее, 4 секунды.

# ls -l testfile*
-rw-r--r--. 1 root root 114573 Jan 27 21:14 testfile.bz2
-rw-r--r--. 1 root root 2147483648 Jan 27 21:13 testfile.dat
-rw-r--r--. 1 root root 2342942 Jan 27 21:14 testfile.gz

А вот тут pbzip2 засиял -- то, что хорошо сжимается, он сжимает лучше.

Надо будет попробовать, спасибо за наводку. В образе диска много областей с нулями -- весьма возможно, это как минимум даст выигрыш в размере образа диска.
спасибо за информацию, я сжимал образы дисков с ноутбуков на домашнем компе, мне нужен был минимальный размер, когда-то давно читал рейтинг архиваторов, тогда bzip2 был хорош, потом наткнулся на мультипоточную версию pbzip2
pbzip2 оказался хуже. Недостаточно быстро распаковывает, сильнее грузит процессор. В результате диск записывается со скоростью 340 мегабайт в секунду, не 440. Выигрыш в размере образа около 10% -- недостаточно лучше, чтобы имело значение.
про pigz круто, спаибо!

про бекап MySQL - лучше пользоваться xtrabackup. Чуть более заморочено, но можно снимать бекап большой базы без ее остановки. Заточено под InnoDB в основном.