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

Я планирую стратегию резервного копирования на основе rsnapshot .

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

# System:
exclude /dev/*
exclude /proc/*
exclude /sys/*
exclude /tmp/*
exclude /run/*
exclude /mnt/*
exclude /media/*
exclude /lost+found

# Application:
exclude /*.pyc
exclude /*.pyo

Интересно, какие еще записи я могу добавить в список исключений, не ставя под угрозу восстановленную систему. Говоря о «общей» системе Linux, можете ли вы предложить дополнительные глобальные расширения, временные каталоги, кэши и т. Д., Которые я могу безопасно исключить?

Прежде всего, вы должны немного прочитать о синтаксисе include / exclude rsync. У меня такое ощущение, что то, что вы хотите сделать, лучше сделать с помощью **шариков, чем *шариков. ( **Расширяется до любого числа записей, в то время как *расширяется только в одной записи , возможно , соответствие нескольких каталогов статей. Подробности в man rsyncсоответствии с Включить / Исключить Шаблонные правила .)

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

Итак, мой rsnapshot.conf на самом деле утверждает (с вкладками, которые делают парсер файла конфигурации rsnapshot счастливым):

interval backup NNN # pick your poison
one_fs 0
exclude /backup/**
exclude /dev/**
exclude /proc/**
exclude /run/**
exclude /sys/**
exclude /tmp/**
backup / ./

и совсем немного. Да, это означает, что я мог бы скопировать немного больше, чем то, что строго необходимо, но это гарантирует, что все, что не предназначено как ephermal, будет скопировано. Из-за rsnapshot, использующего поведение rsync с жесткой ссылкой на дедупликацию, единственная реальная цена для этого - во время первого запуска; после этого, если у вас достаточно целевого хранилища резервных копий разумного размера (по сравнению с вашим общим размером набора данных), это займет совсем немного времени или места на диске. Я исключаю содержимое / backup, потому что именно там я монтирую целевую файловую систему резервного копирования; не исключение этого приведет к ситуации копирования резервной копии в себя. Однако, для простоты, если мне когда-нибудь понадобится восстановить на голом металле, я хочу сохранить точку монтирования!

В моем случае я также не могу разумно использовать one_fs 1; Я использую ZFS с ~ 40 файловыми системами. Перечисление всех этих явных явлений станет кошмаром для обслуживания и сделает работу с файловыми системами ZFS намного более сложной, чем это необходимо.

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

Большая часть того, что вы пытаетесь сделать, может быть выполнена простым использованием one_fsнастроек. Набор файловых систем , которые вы хотите включить в резервных копиях, а затем использовать этот параметр , чтобы игнорировать все остальное ( proc, sys, devи т.д.). Я бы добавил, /lost+foundпотому что этот каталог всегда должен быть пустым, если вы не сделали резервную копию поврежденной файловой системы, и в этом случае вы, вероятно, захотите сделать резервную копию всего, что было fsckвосстановлено. Кроме того, .pycи .pyoвообще не должно быть в корневом каталоге, поэтому я бы тоже удалил эти строки. /tmpи /var/tmpявляются единственными оставшимися путями в «общей» системе, которые содержат данные, которые можно надежно исключить из резервных копий. Так что, возможно, попробуйте что-то вроде:

one_fs 1

exclude /tmp/
exclude /var/tmp/

Я считаю, что лучше иметь список пакетов, содержимое / etc, / home и любые пользовательские / системные данные из / var и других источников. Обычно быстрее переустановить пакеты и скопировать обратно рабочий конфиг.