В настоящее время у нас есть около 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 подключен непосредственно к коммутатору верхнего уровня.
Обновление: при отсутствии информации от кого-то, кто сделал это на практике, я полагаю, что мой вопрос действительно о том, как работают переключатели. Если три или четыре человека выполняют резервное копирование одновременно, а затем два (разных) пользователя передают файл между собой, смогут ли они передать файл на гигабитной скорости?
Это зависит от использования файлов клиентами, но в целом с гигабитной сетью проблем возникнуть не должно. Time Machine выполняет инкрементное резервное копирование, поэтому при каждом резервном копировании перемещает данные только для новых / измененных файлов. Кроме того, он использует FSEvents для отслеживания изменений файлов на стороне клиента, поэтому (обычно) ему даже не нужно сканировать резервную копию, чтобы увидеть, что изменилось.
тем не мение, это инкрементное резервное копирование на уровне файлов, поэтому, если у каких-либо клиентов есть большие файлы, которые часто меняются (базы данных, контейнеры виртуальных машин, временные файлы рендеринга видео и т. д.), они потребляют как пропускную способность, так и емкость сервера, копируя весь файл каждый час.
Однако несколько рекомендаций:
Во многих случаях имеет смысл исключить папки / Applications, / Library и / System из резервной копии (и если вы исключите / System, это дает вам возможность исключить все системные файлы и приложения - в основном, скрытый unix части ОС). Это сэкономит место в резервной копии. Если клиент умирает, вы не сможете выполнить восстановление с нуля, но вы можете переустановить ОС (или повторно создать образ), затем использовать Помощник по миграции для восстановления всей учетной записи пользователя из резервной копии, а затем переустановить приложения и стороннее программное обеспечение. .
Первоначальный снимок будет фактически полной резервной копией, поэтому я бы не стал настраивать его сразу на всех клиентах; ошеломить их. Кроме того, резервное копирование через Wi-Fi обычно нормально, но делайте первоначальный снимок через гигабит.
Time Machine теперь поддерживает несколько целей, поэтому вы можете оставить резервные копии USB на месте и просто добавить сервер в качестве целевого объекта. Кажется, довольно разумно переключаться между целями, когда доступно несколько, или просто использовать то, что доступно, если нет. Я верю в разнообразие резервных копий, и это дает вам хотя бы немного разнообразия.
Если это действительно окажется проблемой (а я почти уверен, что это не так), есть (не поддерживаемые, но довольно безопасные) способы изменить расписание резервного копирования. Видеть TimeMachineEditor или TimeMachineScheduler.