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

10

Я планирую стратегию резервного копирования на основе 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, можете ли вы предложить дополнительные глобальные расширения, временные каталоги, кэши и т. Д., Которые я могу безопасно исключить?

Paolo
источник

Ответы:

11

Прежде всего, вы должны немного прочитать о синтаксисе 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.

CVn
источник
1
exclude /somepath/*прекрасно в этом случае; это исключает все /somepath/, как и ожидалось. Вам не нужно, **потому что нет необходимости смотреть глубже, когда все в /somepath/уже исключено.
Мартин фон Виттих
Или просто используйте exclude /somepathи игнорируйте эти каталоги, а не только их содержимое.
Фрэнк Кастерс
4
@spaceknarf Это нарушает монтирование, когда вы восстанавливаете на голый металл, потому что тогда точка монтирования не существует.
CVn
4

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

one_fs 1

exclude /tmp/
exclude /var/tmp/
depquid
источник
Я действительно не имею в виду /*.pycи , /*.pycно всей системы *.pycи *.pyo, я установил , что. Я не уверен, что если one_fsустановить, 1может исключить все, что я хочу, хотя.
Паоло
1
Что если системный пакет использует такие файлы?
depquid
Вы правы, но я почти уверен, что каждый файл .py будет автоматически перекомпилирован рано или поздно.
Паоло
3
Возможно, но в моей системе такие файлы устанавливаются вендорскими пакетами. Это означает, что если система будет восстановлена ​​из резервной копии, файлы, которые, по мнению диспетчера пакетов, будут отсутствовать. Вы спрашивали о решении для «общей» системы Linux, и я не думаю, что всегда можно предположить, что такие файлы могут быть потеряны без проблем.
depquid
Стоит отметить, что я забыл сказать в Q., что также следует исключить привязки, чтобы избежать дублирования данных.
Паоло
1

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

Шон Перри
источник
Почему установка пакетов, которая включает в себя запись всех системных файлов, а также обработку конфигурации и метаданных, будет быстрее, чем простое копирование файлов?
depquid
По моему опыту, когда требуется реальное резервное копирование, вы также обнаруживаете, что не правильно хранили и документировали все сведения о системе. Сосредоточение вместо этого на отдыхе, а не на восстановлении делает это легче, быстрее и чаще. Очевидно, YMMV.
Шон Перри