"Имеется NAS Synology на 10ТБ ". Вопрос в производительности этой конфигурации. Вдруг там R5 из 3 дисков по 10tb 7200rpm. Бывает необходимо реализовать схему где данные сначала копируются на быстрые диски (SSD) и только потом, неспешно, переносятся на медленную емкость.
Если нужно делать полные бэкапы и влезать в окно бэкапа, нужно понять где узкое место. Это может быть источник (скорость чтения с сервера, обычно последовательная), получатель (NAS, обычно тоже последовательная запись), сеть.
Вы решили для себя что это сеть, но посмотрите реальную нагрузку за сеть во время бэкапа. NAS может и не покажет, но любой сервер включает в себя средства мониторинга и диспетчер задач вам покажет и нагрузку на сеть и нагрузку на диски.
Кстати, общую пропускную способность сети можно немного поднять если включить на всех этапах следования пакетов (ОС/сетевая карта/коммутатор/сетевая карта/ОС) Jumbo frame. Это позволит снизить накладные расходы и увеличить скорость передачи реальных данных. 3-5% повышение производительности без смены железа.
Кроме перечисленных выше возможно еще одно узкое место, это средство резервного копирования. Если по сети передавать данные в один поток, то, как правило, утилизация сети ниже чем при многопоточной передаче.
Вход на сервер DC доступен только администраторам домена по умолчанию. Нужно вспомнить какие логины/пароли задавались при поднятии DC. Пока другим админских прав не дали - администратор один.
Вычисляем каким либо образом емкость требуемую для хранения пользовательских данных. (Отдельно можно сколько образ ПК будет весить и отдельно - пользовательские данные). Не всегда пользователи хранят данные там где мы ожидаем. До сжатия.
Прикидываем сжатие. Пусть 0,8 (видосики и фоточки много занимают и плохо сжимаются).
Умножаем полученную цифру на требуемую глубину архива. Пусть 3 мес, раз в месяц полный, раз в неделю дифф (0,1 от полного).
Приходим к руководству и озвучиваем примерный расклад:
если нужно, можем бэкапить данные на компах пользователей.
это обойдется в Х терабайт. Нужную емкость подобрали, стоить будет ХХ руб от вендора такого.
узлы сетей вот здесь и вот здесь нужно обновить до гигабита и 10 аплинка. Обойдется в х руб.
следить за всем этим надо, нагрузка на ИТ возрастет. Если не сегодня, то завтра готовьте котлету денег на новую должность.
Важно при этом убедиться руководство понимает о каком примерно уровне защиты вы говорите, и о приблизительности ваших расчетов. Вендора можно заменить, данных может оказаться больше или меньше. При таком копировании просто появляется надежда на то что у пользователя что-то можно будет восстановить.
С другой стороны - сетевая папка и приказ в котором все должны хранить важные данные не у себя на компах. Это тоже не бесплатно (емкости под бэкапы тоже нужны), но явно дешевле в эксплуатации.
Решение тут должен принимать не админ, а руководитель. Админ должен снабдить руководителя вводными данными.
не хочется покупать лишний монитор, ок. Но можно же sata->usb переходник взять, он сильно дешевле стоит. Вытащить диск из компа, подключить к ноуту и делать свое дело.
Теоретически это возможно. На практике, если даже взлетит, то как только вы что-то поломаете в настройках сети, вы потеряете возможность что-то исправить.
На устройствах не имеющих выхода на монитор есть возможность залить образ при неисправности, или сбросить настройки в дефолт. Тут такой возможности нет.
А еще можно не создавать дополнительный шаг с QEMU, просто подключить диск и поставить на него нужную ОС с флешки, отключив свой родной диск.
Смотрю по ним много отзывов в днс негативных. Скорее всего при самом начале эксплуатации он показывал себя лучше и со временем ему поплохело.
Просто ждите пока сдохнет окончательно и отнесите в гарантию. Важные данные на нем не стоит хранить.
mistakenatures, не партесь по поводу многоканальности. Поймите сколько памяти вам в итоге нужно и установите. Основная проблема у вас будет состоять в том чтобы эта память заработала. А частота и многоканальность это дело десятое.
Как это ни странно, но вроде сжимаются файлики по отдельности. Для каждого crc формируется, для разных типов данных вроде даже можно настроить свои алгоритмы сжатия. Логика есть - зачем тратить время на сжатие уже сжатого zip архива если можно просто его записать?
Прикольно, у них отдельно даже кабели продаются, наконец кто-то додумался.
Вот раньше, когда небо было голубее, а трава зеленее, каждый проводок был окрашен в цвет соответсвующий его назначению. На проц должны идти желтые 12в и черные (земля). И можно было втыкая понять то ли питание ты вообще втыкаешь. А сейчас все черное и хоть мультиметр втыкай в каждый контакт. Экономия блин. Проблема в том что если разъемы со стороны потребителей установлены стандартами (cpu, gpu, sata), то вот со стороны БП каждый производитель может что угодно налепить и кабель от одного бп нельзя просто так пристегнуть к разъему другого БП, даже если все механически втыкается.
Судя по мануалу от бп первым нужно воткнуть MB 12v1. С большой долей вероятности этого хватит для запуска ПК и работы. (хотя нужно почитать мануалку по материнке, вдруг что изменилось). Еще в комплекте идет P4 кабель на CPU, можно его во второй разъем подключить на материнке и в P8 12v2 на бп
Кабель от be quiet нужен вот такой (по фото непонятно оно или нет), парт номер CC-7710. Странно что производитель слегка недокинул полкабеля в комплект.
При необходимости есть еще переходники с pci-e на 8p cpu. По крайней мере обратный вариант часто попадался, должны быть и такие. Это если не искать конкретный провод от be quiet и есть свободные pci-x кабели.
Вот про "сжатие 1.2-1.3" можно подробней? Просто вопрос про шифрование, а всплывает сжатие. Насколько я помню в ZFS можно было отдельно включать сжатие, шифрование, дедупликацию. Логично что несжатые и не дедуплицированные файлы больше шансов на восстановление имеют. Сжатие уменьшает вероятность восстановления, а дедупликация уменьшает вероятность восстановления сразу множества файлов.
rPman, как-то диски же надо подключать к серверам. Судя по всему выбора у человека особо нет. Контроллер еще со времен Centos 5. Даже если там и была батарейка, то давно сдохла и кешировать там можно только чтение, jbod не предумотрен.
Если заранее известно что на том конце пользователи (по одному), то заранее известив их о профилактических работах и возможных обрывах связи на 5 минут, можно выдергивать по одному и укладывать как нравится.
Если на том конце серверное оборудование или телеком оборудование, то сложнее. Лучше в выходные/ночные.
Fostok, дефолтное имя "Администратор" известно всем и всегда. Остается только пароль брутфорсить. Поэтому такие дефолтные наименования отключаются в последних версиях ОС.
Я немного подумал и не могу понять архитектуру с 192.168.0.0/20. Вот есть у нас некий охранник, у которого cms и сведены все камеры. Предположим он в сети 192.168.10.0/24 (192.168.10.50 шлюз 192.168.10.1). И его cms обращается к камере (ну или регистратору) в сети 192.168.2.0/24 (192.168.2.22 шлюз 192.168.2.1).
Микротик про сети 24 не знает ничего, у него одна большая сеть 20. Я не понимаю как пакет от cms попадет камере?
И даже если CMS в сети 192.168.0.0/20, пакет до камеры дойдет, но вот камера обратно ответ не сможет отправить, т.к. для нее 192.168.10.50 находится в другой сети и она отправит пакет шлюзу на 192.168.2.1, а шлюза и нет.
Если нужно делать полные бэкапы и влезать в окно бэкапа, нужно понять где узкое место. Это может быть источник (скорость чтения с сервера, обычно последовательная), получатель (NAS, обычно тоже последовательная запись), сеть.
Вы решили для себя что это сеть, но посмотрите реальную нагрузку за сеть во время бэкапа. NAS может и не покажет, но любой сервер включает в себя средства мониторинга и диспетчер задач вам покажет и нагрузку на сеть и нагрузку на диски.
Кстати, общую пропускную способность сети можно немного поднять если включить на всех этапах следования пакетов (ОС/сетевая карта/коммутатор/сетевая карта/ОС) Jumbo frame. Это позволит снизить накладные расходы и увеличить скорость передачи реальных данных. 3-5% повышение производительности без смены железа.
Кроме перечисленных выше возможно еще одно узкое место, это средство резервного копирования. Если по сети передавать данные в один поток, то, как правило, утилизация сети ниже чем при многопоточной передаче.