как скрипт может контролировать количество запущенных им в фоне задач

bash параллельное выполнение (комментарий) + jobs

jobs

уж лучше gnu parallel тогда.

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

Тут скорее вопрос не в вычислительных ресурсах, а в скорости сети и работы накопителя.

Может что-то готовое использовать? bacula/bareos вроде в каком-то виде умеет concurrent задания с файловым хранилищем выполнять. (хотя сам не пробовал)

bash параллельное выполнение (комментарий) + jobs

Это я уже прочитал, мне этого функционала недостаточно. Там описано как запустить, параллельно несколько процессов, но мне также надо контролировать, сколько процессов запущено и по мере завершения запускать новые.

уж лучше gnu parallel тогда.

Кажется то что надо :)

Тут скорее вопрос не в вычислительных ресурсах, а в скорости сети и работы накопителя.

Сетка выдает 40 мегабайт в секунду (до удаленного сервера) Винты шуршат на 1000 мегабайт в секунду

Я уже применил оптимизацию у архиватора, стал использовать 7za, чтобы в многопоточном режиме паковать. Но все равно, я думаю еще много чего можно выжать из сервера :)

Может что-то готовое использовать? bacula/bareos вроде в каком-то виде умеет concurrent задания с файловым хранилищем выполнять. (хотя сам не пробовал)

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

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

Mydumper - бакапилка mysql многопоточная.
А для многопоточного бакапа файлов рекомендую restic.

Когда бэкапишь с ресурсами кто-то работает?
Если да - подумай, нужно ли тебе утилизировать диски и сеть на 100%?
Получишь тормоза у пользователей - пойдут жалобы

Посмотри в сторону zfs - кладешь все на zfs, снапшотишь и пересылаешь снапшот(первый полный - потом инкрементальные) на удаленный сервер

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

mysqldump | pigz | ssh example.com "cat > backup.sql.gz"

А буквально по твоему запросу тебе не только gnu parallel подойдёт, но и старые добрые xargs и make.

Если да - подумай, нужно ли тебе утилизировать диски и сеть на 100%?

Именно по этому ускоряю бекап, чтобы за ночь, пока никто сервак не использует все успеть забекапить.

Посмотри в сторону zfs - кладешь все на zfs, снапшотишь и пересылаешь снапшот(первый полный - потом инкрементальные) на удаленный сервер

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

Заказчику не нравится зависимость следующих слоев бекапа от предыдущих

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

1. Делать ежедневно инкрементальный бекап, а в начале недели начинать заново.

2. У, например, rdiff-backup самая последняя копия полная, а инкрементные устремлены в прошлое.

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

А можно так на 7za? Я помню сталкивался давно с какими-то ограничениями gz, то ли ему не нравилось большое количество файлов в архиве, то ли большие файлы. В итоге я от него ушел на 7za и еще 7za умеет использовать несколько ядер процессора.

заказчик отказывается использовать инкрементальный бекап

Для хранения - неразумно. Для переноса - разумно. «Разделяй и властвуй».

А можно так на 7za?

Можно, но нужно ли?

man 7za:

Backup and limitations
  DO NOT USE the 7-zip format for backup purpose on Linux/Unix because :
   - 7-zip does not store the owner/group of the file.

Я помню сталкивался давно с какими-то ограничениями gz, то ли ему не нравилось большое количество файлов в архиве

gz - это компрессор, а не архиватор, он сжимает один поток байтов. Именно поэтому перед ним в пайп ставят архиватор, традиционно tar.

то ли большие файлы

gzip нормально жмёт большие файлы. Размер некорректно показывает, но это никого не волнует.

gzip нормально жмёт большие файлы.

Да он в принципе и не файлы жмёт, а поток байтов, на длину которого ему глубоко наплевать.

Дык у тебя после передачи zfs снапшота на другой стороне будет полная копия по состоянию на время последнего снапшота.
Чтобы восстановиться - не нужно накатывать эти инкрементальные бэкапы.
Плюсом будет - ты можешь делать снапшоты каждый час, например, занимает несколько секунд и иметь возможность
сразу же получить копию на любой из этих моментов снапшота.
А-ля стендбай сервер, и для БД это будет работать

и для БД это будет работать

Как это может работать для БД, если твоя ZFS не знает и знать не может, что СУБД придерживает в RAM.

Как это может работать

Ты что? На святое замахнулся? ZFS супер продвинутая фс, она мож всё. )

mysql << EOF
FLUSH TABLES WITH READ LOCK;
system zfs snapshot data/db@snapname
UNLOCK TABLES;
EOF

FLUSH TABLES WITH READ LOCK

Ещё вдобавок рекомендуют делать FLUSH LOGS, однако этого всё равно недостаточно для innodb таблиц. При запуске mysql на скопированных таким образом данных, он говорит «последнее завершение работы не было успешным, восстанавливаю данные по журналу транзакций». Оно может и не критично выходит в итоге, но полностью целостным такой backup назвать нельзя.

Ну дамп(тоже по большому счету не бэкап) делает копии только закоммиченных транзакций.
Чем он будет отличаться от БД с откатом до последней закоммиченной транзакции?

Изобрёл mydumper

Скорее всего ты в диски упрешься, если бекапы не жмешь. Если жмешь, то многопоток скорее всего есть уже в архиваторе или включается ключами. Я люблю xz с -T параметром для пожатия tar-ов. Вообще xz по скорости/степени пожатия текста и скорости распаковки как по мне рулит.

7zip плохой формат для бэкапов в linux-е. Лучше tar + то что нравится.

Спасибо всем, кто указал мне на недостатки 7z, я к сожалению упустил то, что он не сохраняет permissions.

Мне удалось уговорить заказчика на двойной бекап:

1. rsync будет делать бекап на отдельный сервер в другом датацентре. (это спасет от выхода из строя основного сервера)

2. буду дополнительно делать инкрементальный бекап на самом сервере, в директорию с правами на запись только у root, с историей X дней. Это спасет от случайного/намеренного удаления файлов девелоперами, которые имеют доступ к серверу. Посоветуйте хорошее решение под линукс, позволяющее делать инкрементальный бекап с сохранением истории некоторой глубины.

Я это так вижу - я указываю источник информации и место куда класть бекапы, а также сколько бекапов хранить. Мне надо, чтобы эта система сама поддерживала указанное количество «слоев» в архиве. Что можно использовать из проверенного и хорошо зарекомендовавшего себя?

С базами мне понравилось решение дампить напрямую в архив, плюс еще параллельно несколько бекапов, с этим определился.

У тебя прод не сложится от таких оптимизаций?

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

бекап баз тоже теперь будет без предварительного дампа, а сразу в архив

Убедись, что из этого бекапа можно поднять базу. Два раза убедись. Три раза.

Как раз этот бекап использую, для переноса данных на новый сервер, так что бекап пройдет боевое крещение.

Я решил проблему быстрого бекапа сжатием zstandard и автоматизацией передачи по sftp

https://github.com/ismt/fast-mysql-dump

Что касается многопоточность на питон это несложно

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

Что касается бэкапа вебконтента то лучше rsync, а точнее lsyncd

Что касается бэкапа вебконтента то лучше rsync, а точнее lsyncd

Я собираюсь использовать rsync, но кроме него мне еще нужна система, позволяющая хранить историю изменений за некоторое время.

rsync, например, не спасет, если кто-то злонамеренно модифицирует исходные файлы, rsync точно также их синхронизирует на бекапе. Мне как раз нужна возможность откатиться на несколько дней назад.

Используйте снапшоты, их поддерживает btrfs, zfs, nilfs2

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

Я смотрел rdiff, но как я понял он не умеет усекать количество слоев в архиве. Мне нужно, чтобы я мог контролировать глубину архива, удаляя слишком старое.

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

Поэтому схема прод сервер - бэкап сервер с снэпшотами интересней, чем бэкап через архиваторы

Что касается старых файлов то после rsync можно их дочищать find

Но если таки нужны инкрементальные архивы, то https://ru.wikipedia.org/wiki/DAR_(%D0%B0%D1%80%D1%85%D0%B8%D0%B2%D0%B0%D1%82%D0%BE%D1%80)

Я смотрел rdiff, но как я понял он не умеет усекать количество слоев в архиве.

Ну просто говоришь ему удалить одну самую старую копию. Просто будет в кроне не одна команда, а две.

Ну просто говоришь ему удалить одну самую старую копию. Просто будет в кроне не одна команда, а две.

Можно подробнее, я наверно упустил этот момент изучая rdiff

Скажем имя полный архив и еще 13 слоев (итого 14 объектов):

- Полный архив на первое число

- Слой 1 на второе число

- Слой 2 на третье число

...

- Слой 13 на 14-е число

Я могу дать команду склеить полный архив и первый слой в один объект, так чтобы это стал полный архив на дату первого слоя?

Я же прямо в этом треде писал

У, например, rdiff-backup самая последняя копия полная, а инкрементные устремлены в прошлое.

«Полный архив» - всегда последний. Для удаления самого старого состояния ты просто удаляешь файлы разниц между старым и на-один-новее-чем-старым.

Вот, например, отчет по моему бекапу:

# rdiff-backup --list-increment-sizes /mnt/backup/home/
        Time                       Size        Cumulative size
-----------------------------------------------------------------------------
Wed Jan  1 03:46:02 2020          157 GB            157 GB   (current mirror)
Tue Dec 31 03:49:01 2019         17.8 MB            157 GB
Mon Dec 30 03:46:01 2019         6.93 MB            157 GB
Sun Dec 29 03:11:01 2019         15.6 MB            157 GB
Sat Dec 28 03:09:01 2019         10.8 MB            157 GB
Fri Dec 27 03:22:01 2019         12.9 MB            157 GB
Thu Dec 26 03:22:32 2019         14.5 MB            157 GB
Wed Dec 25 03:42:01 2019          104 MB            157 GB
Tue Dec 24 03:47:44 2019         20.2 MB            157 GB
Mon Dec 23 03:29:32 2019          182 MB            157 GB
Sun Dec 22 03:49:02 2019          106 MB            157 GB
Sat Dec 21 03:45:45 2019         12.7 MB            157 GB
Fri Dec 20 03:35:02 2019         14.4 MB            157 GB
Thu Dec 19 03:45:54 2019          160 MB            158 GB
Wed Dec 18 03:42:01 2019         9.93 MB            158 GB
Tue Dec 17 03:30:01 2019          413 MB            158 GB
Mon Dec 16 03:42:02 2019         5.24 MB            158 GB
...~40 строк...
Tue Oct 29 03:23:01 2019         21.2 MB            162 GB

Вот скрипт:

# cat /etc/cron.daily/backup_home
#!/bin/sh
BMOUNT=/mnt/backup
BDIR=$BMOUNT/home

/usr/bin/ionice -c3 -p $$

/usr/bin/mount -o remount,rw "${BMOUNT}"

while /usr/bin/df --output=pcent "${BMOUNT}/" | /usr/bin/awk 'NR==2&&int($1)<=90 {exit 1}'; do
        LASTSNAPSHOT=`/usr/bin/rdiff-backup --list-increments "${BDIR}" | /usr/bin/awk 'NR==1{print $2;}'`
        LASTSNAPSHOT=`expr $LASTSNAPSHOT - 1`
        /usr/bin/rdiff-backup --remove-older-than ${LASTSNAPSHOT}B --verbosity 2 "${BDIR}" || break
done

/usr/bin/rdiff-backup \
        --no-compare-inode \
        --exclude-globbing-filelist /etc/rdiff-backup/exclude.list \
        /home "${BDIR}/"
/usr/bin/mount -o remount,ro "${BMOUNT}"

У меня здесь хранится неопределённое число копий, самые старые удаляются пока на разделе не останется 90% свободного места.

Просто делать rdiff-backup --remove-older-than 14B.

Спасибо, получается rdiff то, что надо. Буду внедрять его. Вопросов больше не имею.

как скрипт может контролировать количество запущенных им в фоне задач

ps --ppid $$ | wc -l

?

Есить скрипт от vodz как переделать это в многопоточное ? (комментарий)

А вообще xargs/make/parallel уже написаны.

А вообще .* уже написаны

Данный факт никого в нашей индустрии не смущает уже лет 20. Часто проще написать новое, чем выбрать из уже написанного.

Кстати, поставить rdiff на centos 8 - это тот еще квест по поиску rpm-ок.

это тот еще квест

Какой квест? https://pkgs.org/download/rdiff

Это для centos 7, он почему-то не видит python.

Для 8-ки можно найти по фразе «rdiff-backup el8», только на одном сайте есть rmp-ки.

только на одном сайте есть

«Имя, сестра, имя!»

http://dl.marmotte.net/rpms/redhat/el8/x86_64/rdiff-backup-1.2.8-31.el8/

Написал же в гугле набираем «rdiff-backup el8», там же находятся python2-pyxattr и pylibacl, которых тоже не найти для centos 8.