Жизнеспособность сервера Mac OS X 10.9 Time Machine в офисной среде
В настоящее время у нас есть около 20 Mac OS 10.9 MacBook Pro (почти все с твердотельными накопителями) для резервного копирования на отдельные USB-накопители. Я хотел бы объединить их в один массив дисков drobo thunderbolt, подключенный к серверу Mac Mini (с сервером 10.9) с использованием сервера времени.
Мой вопрос, будет ли это масштабировать до 20 пользователей? Примеры, которые я видел, кажутся вершинами из 5 или 6 пользователей, и это нелегко для меня проверить (я бы не стал просить всех делать резервные копии в массиве, а затем переключаться обратно на USB-накопители, если это приведет нашу сеть колени). Моя главная задача - насытить нашу гигабитную сеть, так как машина времени выполняет резервное копирование каждый час для каждой машины, поэтому обычно в любой момент времени резервное копирование выполняется парой людей. У нас также иногда есть люди в нашей сети 802.11ac, а не в Ethernet (обычно подключенные через 802.11n, пока люди не обновятся до более новых машин), но большую часть времени люди подключаются к нашим дисплеям Thunderbolt, которые имеют гигабитное соединение Ethernet.
Наша топология сети - это один 32-портовый гигабитный коммутатор с 5 меньшими гигабитными коммутаторами на каждом настольном кластере. Сервер Mac mini подключен напрямую к переключателю верхнего уровня.
Обновление: при отсутствии информации от кого-то, кто сделал это на практике, я полагаю, что мой вопрос действительно о том, как работают переключатели. Если три или четыре человека выполняют резервное копирование одновременно, а затем два (разных) пользователя передают файл между собой, смогут ли они передавать файл на гигабитных скоростях?
1 ответ
Это зависит от использования файлов клиентов, но в целом с гигабитной сетью у вас не должно быть никаких проблем. Time Machine выполняет инкрементное резервное копирование, поэтому она перемещает данные только для новых / измененных файлов при каждом резервном копировании. Кроме того, он использует FSEvents для отслеживания изменений файлов на стороне клиента, поэтому ему (как правило) даже не приходится сканировать резервную копию, чтобы увидеть, что отличается.
Однако это инкрементное резервное копирование на уровне файлов, поэтому, если у каких-либо клиентов часто изменяются большие файлы (базы данных, контейнеры виртуальных машин, временные файлы рендеринга видео и т. Д.), Они потребляют пропускную способность и емкость сервера, копируя весь файл каждый час.
Несколько рекомендаций, хотя:
Во многих случаях имеет смысл исключить папки /Applications, /Library и /System из резервной копии (и если вы исключите /System, это даст вам возможность исключить все системные файлы и приложения - в основном, скрытый Unix). части ОС). Это сэкономит место на резервной копии. Если клиент умирает, вы не сможете выполнить восстановление "с нуля", но вы можете переустановить ОС (или переустановить ее), а затем использовать Migration Assistant для восстановления всей учетной записи пользователя из резервной копии, а затем переустановить приложения и программное обеспечение сторонних производителей.,
Первоначальный снимок фактически будет полной резервной копией, поэтому я бы не стал настраивать его на всех клиентах одновременно; пошатни их. Кроме того, резервное копирование по Wi-Fi, как правило, хорошо, но сделайте начальный снимок через гигабит.
Теперь Time Machine поддерживает несколько целей, поэтому вы можете оставить резервные копии USB на месте и просто добавить сервер в качестве цели резервного копирования. Кажется, что он достаточно умел вращаться между целями, когда доступно несколько, или просто использовать то, что доступно, если нет. Я большой сторонник разнообразия резервных копий, и это дает вам хотя бы немного разнообразия.
Если это оказывается проблемой (и я вполне уверен, что не будет), есть (неподдерживаемые, но довольно безопасные) способы настройки расписания резервного копирования. См. TimeMachineEditor или http://www.klieme.com/TimeMachineScheduler.html.