Резервное копирование потокового сервера

То, что мы делаем, - это наличие нескольких сетей FC SAN, каждая из которых синхронизирована друг с другом в разных центрах обработки данных, и каждый из них подключен к банкам серверов, выступающих в качестве серверов-отправителей, транслирующих хранилище FC в NFS или CIFS/SMB. Эти серверы затем разделяются на VIP-блоки с балансировкой нагрузки, которые, в свою очередь, подают аналогичные VIP-блоки веб-серверов, которые затем передаются через FW/LBs во внешний мир.

Фактический контент периодически привязывается из одного или нескольких блоков FC SAN к выделенному блоку SAN, который затем резервируется на диск на другом сайте, затем ленты сохраняются в Iron Mountain. Я в потоковом бизнесе:)

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

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

Допустим, один из ваших вопросов - "Как внутренняя архитектура YouTube построена для этого". несмотря на то, что вы никогда не использовали вопросительный знак в своем сообщении, ответ на него заключается в том, что Google невероятно огромен и имеет множество серверов, разбросанных по всему земному шару, и вы можете быть уверены, что данные хранятся на более чем одной машине, поэтому в случае, если один из них выходит из строя, данные могут продолжать потоковую передачу.

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

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

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

Теперь вы выясняете, почему настроить потоковое видео / аудио и сохранить его надежность не так просто. Чтобы получить полное решение для резервного копирования, вам необходимо:

• Дополнительные серверы для хранения зарезервированного контента.
• Достаточная доступная пропускная способность (в отдельной внутренней сети) для резервного копирования.
• Сценарии для своевременного копирования содержимого или автоматического резервного копирования при добавлении файлов на сервер.

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

Как отметил Chopper3, вы можете встроить в инфраструктуру необходимость делать "резервные копии", потому что при добавлении контента он автоматически зеркально отражается.