У меня есть сценарий, который запускает резервное копирование системных файлов через tar в качестве задания cron для моего сервера. Каждый раз, когда скрипт запускается, он завершает задачу как успешную. Все резервные копии были протестированы и оказались работоспособными, а не поврежденными.
Но моя система на какое-то время зависла и зависла, и мои команды были медленными. Это такое же состояние, как когда я запускал графический рабочий стол. Итак, почему система останавливается после запуска tar?
Это команда в моем сценарии на crontab для запуска резервного копирования tar.
tar -zcvf tarbackup.tar.gz --one-file-system \
--exclude=/run \
--exclude=/tmp \
--exclude=/home \
--exclude=*.system.tar.gz \
--exclude=*.home.tar.gz \
/
ИЗМЕНИТЬ:
Чтобы решить эту проблему, мне приходилось каждый раз перезагружаться. Я хочу понять, почему это происходит, поэтому я могу изучить возможность запуска резервного копирования tar без перезагрузки системы.
Этот ответ функционирует таким образом, чтобы вам не приходилось манипулировать глобальным системным файлом dirty_bytes / dirty_background_bytes, который может повлиять на другие приложения, когда резервное копирование не выполняется.
Честно говоря, это немного взлом, но я оставляю его на случай, если он вам пригодится.
tar -zcv --one-file-system \
--exclude=/run \
--exclude=/tmp \
--exclude=/home \
--exclude=*.system.tar.gz \
--exclude=*.home.tar.gz \
/ | \
dd bs=2048k oflag=sync of=tarbackup.tar.gz
Остановка происходит во время записи грязных страниц на диск; вы можете быстро ознакомиться с проблемой на эта статья LWN. По сути, текущее значение по умолчанию для объема памяти, используемой для записи в кэш, слишком велико. Попробуйте установить / proc / sys / vm / dirty_background_bytes на 104857600 и / proc / sys / vm / dirty_bytes на 209715200. Вы можете сделать это для текущей загрузки, запустив sysctl или навсегда путем редактирования /etc/sysctl.conf.