Марк Розенталь: Лучше не пользоваться NAS-ами. Они для дома подходят, а для рабочих нужд -- не очень. По вынужденному опыту использования готовых NAS'ов (QNAP, Synology), постоянно с ними какие-то грабли были. Регулярно отваливались хранилища, почему-то слетали права на папки и пользовательские пароли. Более или менее стабильно оно работало только по iSCSI.
Если вам там реально 8 килоевро выделяют, купите лучше что-нибудь в духе HP Microserver, можно даже Gen7. Там 4 дисковых отсека, и при желании можно воткнуть 5-ый диск. Поставьте на него чистый линух или фрю, ну или даже винду, и бэкапьте на него. Просто "готовые коробки" типа NASов довольно тяжело дебажить, если с ними какие-то проблемы начинаются. Покупаешь такую "проприетарную коробку" -- предусмотри бюджет на покупку техподдержки по ней. Иначе может наступить очень неописуемый случай. А когда всё собираешь и настраиваешь сам -- оно и разбираться с этим проще, если вдруг что.
АртемЪ: Артём, бывают такие задачи, когда "окно бэкапа" лимитировано. Одно дело, когда вам нужно забэкапить пару гигов, и это делается за 10-20 минут. А другое -- когда забэкапить нужно несколько десятков теров, причём сделать это так, чтобы то место, откуда вы бэкапы делаете, не испытывало серьёзных просадок по производительности в этот момент.
И тут уже производительность хранилища для бэкапов начинает играть заметную роль. И приходится изобретать способы, позволяющие ускорить выполнение резервного копирования -- делать снапшоты, по ним высчитывать инкременты, делать RAID10 на хранилищах, ставить 10-гигабитные сетевухи, и прочие ухищрения применять.
У нас, например, общий объём виртуальных машин, которые нужно бэкапить -- около 120 Тб. Ежедневный объём бэкапов в среднем -- около 20 Тб.
nfire: internet тут следует понимать буквально -- как "меж-сетевой", а не "работающий через интернет" :-) Хотя и межсетевой -- это тоже натяжка. При маршрутизации iSCSI-трафика будут получаться заметные просадки по производительности.
Александр: Ну это, как говорится, кому что дороже. RAID5 позволяет сэкономить на дисках. А если совсем по серьёзному всё делать, то помимо RAID-ов бэкапы должны быть минимум в двух копиях, и лежать в разных географических местах (в разных зданиях, а лучше -- в разных городах).
У вас есть виртуальная инфраструктура и нет мониторинга?! Срочно делайте мониторинг всех виртуалок и ESX-хоста. У вас там, похоже, дырки есть в гостевых системах, поэтому аномальный исходящий траффик может быть следствием взлома или атак в стиле DNS/NTP amplification. Патчите все гостевые системы и настраивайте мониторинг, который вам сообщит, если что-нибудь подобное опять начнётся.
The Lost: полного конфига сквида я так и не увидел. Это во-первых.
Во-вторых, книга несколько устарела :-) natd уже давно не используется, так как уже есть встроенный в ядро NAT (по-моему, с FreeBSD 7.0 уже появился). Привыкайте пользоваться родной документацией -- man ipfw, там даже примеры организации NAT есть. Но это лирика.
Отключите пока NAT, и разберитесь с прозрачным прокси. Пакеты на него вообще приходят? Что пишет Squid в логах?
Rad1us: HTTPS невозможно проксировать прозрачно. Потому что это получается атака типа man-in-the-middle. Точнее, проксировать возможно (google for "squid ssl bump"), но это грязный хак, и клиентам такое точно не понравится. Кроме того, при открытии любого HTTPS-сайта при использовании SSL bump браузер будет ругаться на кривой сертификат.
А вот правило http_access deny !Safe_ports действительно запрещает любые подключения на порты вне списка Safe_ports. Но оно не будет препятствовать подключению к сайтам, висящим на стандартных портах.
Не совсем так. Правило http_access deny CONNECT !SSL_ports предписывает сквиду блокировать попытки подключений методом CONNECT на порты, которые НЕ ВХОДЯТ в список SSL_ports. См. подробности по методу CONNECT: en.wikipedia.org/wiki/HTTP_tunnel
The Lost: Я бы добавил, что во фре, в отличие от всяких линуксов, конфиги самоустанавливаемого софта ВСЕГДА ложатся в /usr/local/etc :-) И только если при установке явным образом пользователь указал иное расположение каталогов -- только тогда конфиги могут оказаться где-то ещё. Таким образом схема проста -- конфиги всего дефолтного софта (который идёт в комплекте с системой) всегда лежат в /etc, а конфиги всего, что вы ставите сами -- в /usr/local/etc/
Nik: По моим последним сведениям при поддержке Microsoft в 4-ую самбу запилили поддержку GPO.
Там вроде уровень домена низкий, при выходе в конце 2012, начале 2013 там уровень домена было Win2003. Сейчас может и повыше стало.
Багов ещё многовато. Ну и некоторые вещи делаются с помощью костылей и такой-то матери. Короче, в более или менее серьёзном продакшене я бы это использовать пока не стал.
alovanton: Попробуйте тогда всё же подцепить NAS по iSCSI к серверу.
Что касается "проверенных средств" -- средства копирования на уровне снапшотов виртуальных машин не менее проверены -- у нас, например, бэкапится виртуальная инфраструктура с 20 хостов виртуализации, на которой суммарно пара сотен виртуальных машин :-) И спец-средства, про которые я упоминал -- например, Veeam Backup, также позволяют вытащить отдельный файл из бэкапа.
alovanton: Я правильно понимаю, что у вас виртуальный Windows-сервер, и вы пытаетесь бэкапить диски из этой виртуальной машины прямо из самой виртуальной системы?
Попробуйте просто на этот NAS залить из виртуального сервера Windows какой-нибудь большой файл, на несколько гигабайт. Если оно отвалится в процессе копирования файла на SMB-шару, то проблема или в сети, или в NAS.
Я имел сношения с разными NASами, в том числе и в разрезе задач резервного копирования. Домашние NAS крайне плохо себя показывают для этого, почему-то -- постоянно отваливаются смонтированные сетевые папки. Попробуйте поменять протокол -- заливать по FTP, например, а не по SMB. Во всех случаях, что я сталкивался, помогало только подключение NAS-а по iSCSI внутрь системы, с которой вы делаете бэкап.
Ну и отвлечённое замечание, просто для общего развития. Виртуальные машины обычно бэкапятся с помощью специального софта, который их бэкапит на уровне снапшотов виртуальных дисков.
Николай Савельев: а в чём геморрой, если не секрет? Я линуксами сам не занимаюсь, но в нас в конторе есть линуксовые сервера в домене, вроде всё работает.
На фре тоже всё ровно -- у нас почтовый сервак и прокси (Squid) на фре, авторизуют юзеров через домен, никаких проблем.
Как все это делают -- настраивается групповая политика в домене, и настройки прокси применяются всем пользователям (или принадлежащим определённым OU, или входящим в определённую группу).
coliator: Добавьте перед проверкой значения переменной ret строчку:
echo $ret >> ~/log.txt
После того, как скрипт отработает по крону -- посмотрите, что там в логе будет. Ну и посмотрите почту root'a -- там будет письмо с экранным выводом процесса запуска этого скрипта кроном. Что там пишется по этому поводу?
coliator: Я не силён в bash. А точно там такая нотация: ret=$(ps aux | grep [s]cript | wc -l)
В csh просто по-другому, там это выглядело бы как
ret=`ps aux | grep [s]cript | wc -l`
Ну и стоит убедиться, что в кронтабе этот скрипт таки выполняется именно из bash. Так как по умолчанию кронтаб запускает /bin/sh. Добавьте в скрипт какое-нибудь логирование, из-под какой оболочки скрипт этот выполняется.
Если вам там реально 8 килоевро выделяют, купите лучше что-нибудь в духе HP Microserver, можно даже Gen7. Там 4 дисковых отсека, и при желании можно воткнуть 5-ый диск. Поставьте на него чистый линух или фрю, ну или даже винду, и бэкапьте на него. Просто "готовые коробки" типа NASов довольно тяжело дебажить, если с ними какие-то проблемы начинаются. Покупаешь такую "проприетарную коробку" -- предусмотри бюджет на покупку техподдержки по ней. Иначе может наступить очень неописуемый случай. А когда всё собираешь и настраиваешь сам -- оно и разбираться с этим проще, если вдруг что.