Какие папки не следует резервировать на CentOS?


10

Я использую rsnapshot, чтобы начать резервное копирование установки CentOS 5.5, и мне нужен список папок, которые я, вероятно, должен исключить из резервных копий. Сервер в первую очередь является веб-сервером LAMP и будет обслуживать во время резервного копирования, хотя объем должен быть относительно небольшим. Резервное копирование / var / lib / mysql - плохая идея?

Я предполагаю, что мне не нужно беспокоиться о резервном копировании / proc, какие другие папки не нужно резервировать?

Ответы:


10

Можно почти наверняка игнорировать /proc, /dev, /tmpи /var/tmp.

Хороший случай может быть сделан для игнорирования /var/log(и любых других каталогов журналов), /var/cacheесли у вас есть, и, возможно, части /var/db(хотя вы должны быть осторожны с /var/db: иногда туда попадают действительно важные вещи ...)

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


После того, как вы выбрали материал, который хотите создать резервную копию, и настроили свои списки включения / исключения, убедитесь, что вы провели правильный тест восстановления - возьмите машину с чистого листа и пройдите процесс, необходимый для того, чтобы ваши данные и программное обеспечение снова заработали , без трогательно оригинальной машины.

Если вы не можете управлять этим восстановлением с помощью резервной копии, у вас действительно нет резервной копии ...


/ sys тоже следует игнорировать.
Jmarki

/sysэто еще один хороший один игнорировать - и если у вас есть BIND работает в изолированном окружении вы хотите игнорировать /dev, /procи т.д. под изолированном окружении ...
voretaq7

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

@Server Horror - true, если у вас не настроен удаленный системный журнал, возможно, вы захотите создать резервную копию журналов. Недостатком этого является то, что ротация журналов выглядит (для большинства программ резервного копирования) как каждый измененный файл: делать несколько копий каждого повернутого журнала. Не проблема для некоторых систем, дополнительный день или около того для занятых веб-серверов с подробными журналами доступа ...
voretaq7

1

Единственные папки, которые вам нужны, это /var/wwwи /var/lib/mysqlваш сайт и данные. И резервное копирование, /etc/httpdчтобы получить конфигурацию Apache, если это необходимо. Смотрите здесь для обсуждения резервного копирования по /var/lib/mysqlсравнению с использованием mysqldump.

Если вы можете использовать снимок lvm для резервного копирования, это было бы еще лучше, но обязательно уничтожьте снимок, как только сможете. Снимки Lvm разрушают вашу производительность.


5
Это хорошее начало для резервного копирования MySQL, но высказывание «Единственные папки, которые вам нужны» крайне опасно, особенно когда вы не знакомы с окружением - в других местах могут быть критические данные (например, информация о пользователе / ​​пароле в /etc/passwd& /etc/shadowКлючи SSH под /home, пользовательские скрипты под /usr/local...). Как правило, лучше составить список того, что можно безопасно исключить из резервной копии, а не пытаться захватывать все, что вам нужно, с помощью конкретных включений.
voretaq7

0

Слишком мало информации, извини.

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

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

  • конфигурационные файлы
  • файлы журналов (на случай, если случится что-то неприятное)
  • « данные » - это будут файлы зон для связывания, «дампы» ldap, дампы баз данных и еще много чего.
  • домашние каталоги, если к серверам подключаются настоящие пользователи
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.