Решение для резервного копирования для малых и средних компаний
На данный момент в дата-центре у нас 6 боксов. Каждый из них запускает стек LAMP, и каждый из них требует резервного копирования. Очевидное решение - создать резервную копию всего этого на одной машине, а затем подключить к ней диск и создать резервную копию.
Проблема в том, что некоторые из наших сотрудников (читай: человек, который будет включать диск) ленивы. Так что мне было поручено написать сценарий для резервного копирования каждой из наших машин локально, чтобы затем можно было резервное копирование за пределами площадки в том же духе, что и выше. Однако центр обработки данных взимает плату за 95-й процентиль, и эти резервные копии обходятся компании денег.
Мой вопрос для малого / среднего бизнеса: какой подходящий сценарий мы должны использовать для резервного копирования наших данных? В настоящее время покупка другой машины для резервного копирования - это далеко не возможность, но это будет принято во внимание.
Уже есть ТОННА дополнительных вопросов. Я только что закончил отвечать на один из них. ржунимагу
В Книга О'Рейли "Резервное копирование и восстановление" - отличная книга, если вы хотите прочитать об общей стратегии и некоторых ее возможностях.
Перед тем, как начать, вам понадобится ПЛАН. И план должен иметь смысл и (надеюсь) быть масштабируемым.
Некоторые конкретные вещи, которые вы можете захотеть изучить и рассмотреть:
rsync (всегда личный фаворит)
Как в настоящее время вы выполняете резервное копирование вне офиса?
Если вас устраивает текущее расположение, то вы можете просто ограничить объем полосы пропускания, используемый процессом, выполняющим внешнее копирование, заключив его в оболочку струйка или что-то подобное. Ограничьте пропускную способность до уровня, который заметно ниже вашей платной скорости передачи данных.
Я лично (и на работе) использую rsync для всех резервных копий, так как протокол синхронизации очень эффективен при ограничении объема передаваемых данных. Вдобавок ко всему у него есть собственная опция дросселирования передачи, которую мы используем, чтобы не перегружать исходящую линию ADSL (что было бы неудобно, если бы запуск резервного копирования начался, когда один из нас выполнял задачи удаленного администратора по этой строке ).
Хорошо, ваш первый шаг должен заключаться в том, чтобы оценить, что вы действительно хотите, и создать план резервного копирования, прежде чем создавать решение для резервного копирования. Собака устает, когда ее виляют.
Если бы я был в такой ситуации, я бы сделал вот что.
Если машины были созданы в кикстарте и хорошо управляются, и вы можете воссоздать их из документации, отлично. Если нет, делайте полугодовые образы их на USB-накопители. Ты можешь использовать клонезилла и будет сделано в короткие сроки. Это даст вам относительно быстрый ремонт, если одна из машин загорится или что-то еще.
Вам также понадобится регулярное резервное копирование конфигурации и данных. Не зная, сколько это данных, я бы посоветовал оценить потребности каждого отдельного сервера и определить, что потребуется для места назначения резервного копирования. Как только вы его получите, вы получите гораздо лучшее представление о том, где его разместить.
Оцените. План. Сборка. Тест. В таком порядке, пожалуйста.
Хм. Что ж, наше решение - иметь отдельный сервер резервного копирования в центре обработки данных, но без резервных копий за пределами площадки. Это дешево для нас, потому что мы арендуем целую стойку, но используем только 2/3 ее (и мы очень удобны с провайдером центра обработки данных - это пространство может быть даже бесплатным). я предложил удаленные резервные копии для моего босса, но он отклонил это как слишком дорогое с точки зрения пропускной способности. Он также считает, что вероятность разрушения нашего центра обработки данных слишком мала. Я пожимаю плечами и говорю: «Это ваш звонок».
Что касается самого сервера резервного копирования, то он тоже стоит недорого. Это оборудование потребительского уровня с диском без RAID. Ожидается, что если диск выйдет из строя, в тот же день у меня будет новый, и мы немедленно восстановим резервные копии. Однако программное обеспечение, которое выполняет резервное копирование серверов, отправляется за пределы площадки, потому что это очень мало по сравнению со всеми другими данными. Это также всего несколько пользовательских сценариев оболочки, которые используют Rsync. Я делаю инкрементные резервные копии, создавая архивы каталогов и вращая архивы.
С технической точки зрения этого «достаточно». Он уже несколько раз спасал наши шкуры.
Лично мне нравится backuppc это бесплатно, он объединяет данные, очень настраиваемый, использует базовые инструменты Linux, может создавать резервные копии всех видов ОС, веб-интерфейса и довольно простых конфигураций.
Я использую rsync для центрального резервного сервера; добавьте немного "чередующихся резервных копий" с использованием жестких ссылок для экономии места на диске:
cd /backup/
for i in $( seq 0 4 | sort -r)
do
mv cur.$i cur.$[$i+1]
done
rm -rf cur.5 &
cp -al cur cur.0
Поскольку rsync переместит новый файл поверх старого - жесткие ссылки сэкономят тонну дискового пространства для файлов, которые никогда не меняются (все они ссылаются на один индексный дескриптор), но каждая копия каталога должна содержать каждый файл (не просто символические ссылки на файлы)
rsync имеет ограничитель пропускной способности и встроенное сжатие:
-z, --compress compress file data during the transfer
--bwlimit=KBPS limit I/O bandwidth; KBytes per second
Каждую ночь я выполняю резервное копирование 23 машин на один сервер. Перебор всех машин занимает чуть меньше 2 часов, но я использую локальную машину.
Прямо сейчас есть несколько прилично дешевых дисков емкостью 2 ТБ - и вы можете легко настроить RAID 1, который отражает ваш резервный диск на дополнительный диск, который становится вашим «внешним» диском вращения.