У меня есть веб-сайт, на котором сейчас размещено около 300 ГБ (более 1000 файлов) обучающих видео на провайдере общего хостинга. Мы увеличиваем это примерно на 50 видеофайлов в месяц (~ 20 ГБ). В настоящее время наши резервные копии находятся на настольных компьютерах наших сотрудников, однако я хотел бы настроить что-то более автоматизированное. Я буду изучать другие варианты хостинга, но пока мне хотелось бы получить мнения / улучшения относительно следующего плана резервного копирования на этом сервере.
Будет выполнено резервное копирование файлов двух типов. Первый - это видеофайлы, описанные выше. Их нужно создавать только один раз для каждого файла, поскольку они никогда не изменятся. Второй тип резервного копирования - это файлы с самого сайта. Их следует регулярно создавать резервные копии и отслеживать на предмет изменений. Большинство изменений здесь не будут связаны с изменениями кода, и сотрудники, вносящие изменения, 1) не имеют технической подготовки и 2) распределены по всей территории США. Я не думаю, что решение на основе svn будет работать хорошо, учитывая эти факты.
Итак, вот что я думаю:
Видите ли вы какие-нибудь проблемы с этим подходом? Могу ли я столкнуться с проблемами при первом запуске скрипта из-за большого количества данных, которые должны быть переданы во время первого цикла?
Ваше приложение звучит достаточно часто, поэтому я бы не рекомендовал тратить время на развертывание собственного решения.
Что-то вроде rsnapshot может позаботиться о ваших потребностях в управлении версиями (конечно, при условии, что на целевой машине достаточно места на диске) без необходимости изобретать колесо, когда вы используете свою «резервную базу данных». Вам нужно будет использовать протокол rsync, а не FTP, но вы, скорее всего, в конечном итоге получите меньше данных, передаваемых по сети с помощью rsync.
Если вы хотите быть немного более резким, вы можете дать ФСВС (Fast System VerSioning) взгляд. Это система резервного копирования, которая использует серверную часть Subversion для хранения файлов и отслеживания версий, но не требует от конечных пользователей взаимодействия с Subversion.
Мое личное решение чего-то подобного - S3 и git.
Сначала синхронизируйте все видео с S3. Обратите внимание, что это также обеспечивает некоторую резервную копию вашего веб-сайта, поскольку вы также можете обслуживать файлы прямо из S3, если возникнет необходимость.
Во-вторых, поместите все файлы «с самого сайта» в репозиторий git, и всякий раз, когда вы хотите сделать резервную копию, сделайте фиксацию, а затем поместите копию каталога .git на S3. Обратите внимание, что никто, кроме вас, не должен знать, как работать с git.
Это дает вам простую резервную копию видео и более сложную резервную копию сайта на основе временной шкалы. И, конечно же, хотя я использую S3, вы также можете использовать Dropbox, удаленный хост или что-то еще.
Для меня это звучит неплохо, хотя я думаю, что вы могли бы здесь немного изобретать колесо, поскольку я уверен, что существует программное обеспечение для резервного копирования, которое удовлетворит ваши потребности.
Что касается резервного копирования исходного кода сайта - не лучше ли оставить это ПО для контроля версий?
Существуют программы резервного копирования, которые могут исключать определенные типы файлов (извините, я не могу назвать вам сегодня названия программ, сегодня День взятия Бастилии, а моих коллег нет :)). Это позволит вам создавать резервные копии отдельно огромных файлов (видео) и общих файлов.
Что касается таблицы БД: я бы не стал полагаться на такую сложную вещь в случае чрезвычайной ситуации, например, катастрофы. Я бы полагался только на удобочитаемые текстовые файлы. Вы не знаете, насколько тяжелым будет дело, кроме того, что у вас есть автономный жесткий диск для резервного копирования, с которого вы должны спасти мир, свою компанию и свою задницу. В этом случае вы можете смонтировать HD и открыть текстовый файл за несколько секунд, тогда как извлечение данных из таблицы БД займет несколько минут или больше (если она не повреждена), когда вам лучше делать и думать о.
Интервалы времени: ежедневное сравнение и полное резервное копирование один раз в неделю или два раза в месяц кажется мне разумным и достаточным (я работаю в веб-агентстве, а не в банке). YMMV.
Мы стараемся хранить множество копий одного и того же файла в совершенно разных местах, но при этом знаем, какие файлы являются более новыми. Что бы вы сделали, если бы резервный жесткий диск вышел из строя вместе с машиной, к которой он был подключен? Если у вас не было второй копии этого HD, то у вас проблемы. Дома семьи или друзей - отличное место для хранения зашифрованных дисков, на всякий случай. Затем вы должны управлять паролями и людьми, которые их знают. Родители, муж / жена, начальник, лучший друг и т. Д.
РЕДАКТИРОВАТЬ: это не вопрос для ServerFault.com?
У меня есть одно слово для тебя, друг мой: rsnapshot
Он делает все, что вы перечислили выше, с дополнительным бонусом, заключающимся в том, что вам не нужно писать ни одной строчки кода. Он выполняет резервное копирование только измененных файлов, поэтому после первоначального огромного резервного копирования он будет создавать резервные копии только новых / измененных файлов. Он работает очень быстро, и его легко установить и запустить.