Построение ИТ инфраструктуры небольшого офиса

В данной публикации я сделаю большую подборку статей с моего сайта, касающуюся настройки своей инфраструктуры в небольшом офисе. Это не будет набором лучших практик, скорее просто навигационная статья, объединяющая всё, что у меня есть по этой теме, с моими комментариями и рекомендациями. Я постараюсь передать свой опыт по построению небольших, готовых к эксплуатации, инфраструктур.

Введение

Как я уже сказал ранее, статья будет в основном навигационная, чтобы было проще ориентироваться тем, кто будет искать материалы на эту тему. Написать я ее решил после того, как меня несколько раз попросили помочь с темой планирования и разворачивания различных сервисов в небольшой компании. Это будет актуально для начинающих сисадминов, которые захотят изучить операционную систему Linux и попробовать ее в реальной эксплуатации, так как почти все статьи будут с её использованием.

Некоторые статьи очень старые, так как писались в стародавние времена, когда я сам занимался поддержкой офисов. Сейчас я ушел от этой деятельности, но, как мне кажется, неплохо понимаю специфику и подходы к ИТ в малом и среднем бизнесе. По крайней мере какой-то серьезной критики и замечаний к тому, что я делал, не получал. В общем и целом всё настроенное было адекватно и функционально в плане решения поставленных задач. В Linux подход не сильно меняется со временем, так что старые статьи можно просто взять для справки, как можно сделать, а саму настройку попробовать сделать самостоятельно, или найти в сети более актуальную статью.

И еще раз важное замечание. Не надо принимать мои статьи и рекомендации за истину в последней инстанции. Я просто делюсь своим опытом, таким, какой он есть. К тому же я обычный человек и могу заблуждаться, делать что-то неправильно и советовать ерунду. Если вы видите это, то обязательно пишите об этом в комментариях. Не претендую на лавры крупного специалиста и всезнайки. У меня просто большой практический опыт и им имеет смысл делиться, даже если он не совсем правильный во всем.

Шлюз для небольшого офиса

На базе стандартной ОС

Начнем с основного - доступа в интернет. Для этого нам нужен шлюз. Его выбор будет сильно зависеть от конкретных требований к функционалу и быстродействию. Лично я предпочитаю софтовые шлюзы на базе популярных операционных систем:

• шлюз на centos;
• шлюза на debian;
• шлюз на freebsd.

Сам я начинал с Freebsd, но сейчас, очевидно, это не самый лучший выбор, так как Freebsd растеряла всю свою популярность и мало где используется. А выбор между Debian и Сentos и её клонами — это выбор между вашими предпочтениями. Принципиальной разницы в эксплуатации не будет. Единственный совет — стройте всю инфраструктуру, по возможности, на базе одной операционной системы. Сейчас я выбираю для этого Debian.

Поясню, почему лично мне такой вариант нравится больше всего. Во-первых, унификация. Как я уже сказал, удобно всё делать на базе одной системы. Во-вторых, гибкость настроек. Вы можете реализовать практически всё, что пожелаете. К примеру, настроить openvpn сервер. При этом, вы можете насоздавать любое количество тоннелей с различными параметрами. Например, кого-то посадить на стандартный udp порт, кого-то на tcp. На каких-то тоннелях включить сжатие, где-то убрать и т.д. Это очень удобно. Сюда же можно будет добавить l2tp или что-то еще.

Если нужен прокси сервер - не вопрос. Можно поставить на эту же машину, либо отдельную. Конечный функционал будет зависеть только от ваших познаний в Linux. Еще пример на эту тему - блокировка доступа по странам. Со своим программным шлюзом подобные вещи не представляют особой сложности и быстро настраиваются. В-третьих, шлюзы на Linux, скорее всего будут на базе какого-то типового x86_64 железа или виртуальной машины, что позволяет обеспечить огромное быстродействие и возможность наращивания производительности.

На базе готовой программной сборки

Отдельно стоит рассмотреть программный шлюз на базе преднастроенной сборки. Под капотом там скорее всего будет тот же Linux или Freebsd, но все управление осуществляется через web интерфейс. Пример такого шлюза я разбирал в статье - шлюз на базе clearos. Мне довелось плотно с ним поработать в одной организации, поэтому и появилась статья. Я не могу сказать, что однозначно его рекомендую. Плюс там только в том, что он на базе Centos. В данном сегменте, на мой взгляд, лидер - pfsense. Сам я никогда не разворачивал подобные сборки, если обслуживал инфраструктуру сам, они мне доставались по наследству.

Плюс такого подхода в том, что не нужны специальные знания Linux, чтобы управлять шлюзом. Вся настройка осуществляется через web интерфейс. Соответственно, высоких требований к специалисту, обслуживающему такой шлюз, тоже нет. Вы можете передать такое хозяйство на обслуживание практически кому угодно.

На базе готового аппаратного решения

Здесь речь идет о популярных роутерах на базе Zyxel, D-link, Mikrotik и т.д. На мой взгляд однозначным лидером в этом сегменте по соотношению цена/качество/функционал был Микротик. Но сейчас всё не так однозначно. Микротики по прежнему можно приобрести, но цены уже кусаются. Есть смысл рассмотреть другие бренды. Не хочется подробно останавливаться на этом моменте, потому что он дискуссионный.

Если у вас типовые требования к функционалу шлюза и не смущают цены, то я рекомендую ставить Mikrotik, а не программный роутер. Микротик сэкономит вам кучу времени, так как в готовом виде предлагает функционал, удовлетворяющий процентов на 90-95 потребности типового офиса. По нему много материалов в сети, есть вендорские курсы и сертификация.

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

Выбор сервера для офиса

В этом разделе я рассмотрю вопрос покупки серверов для офиса. Выбор тут обычно состоит из вариантов приобретения:

1. Серверного брендового железа.
2. Серверного железа noname.
3. Десктопного железа.

Мне знакома одна компания, которая много лет все свои сервисы размещала на десктопном железе. Люди искренне не понимали, зачем платить больше, если и так всё работает. При этом у них реально ничего не ломалось. Не сразу, но мне все же удалось убедить перейти на брендовые сервера (HPE).

Переплачивать или нет за бренд - решать руководству. Ваша задача доходчиво разъяснить, в чем разница. У меня есть отдельная статья на этот счет - зачем нужен брендовый сервер. Лично я всегда настаиваю на покупке хорошего сервера, пусть и б.у. если нет возможности купить новый. Сервер обязательно должен быть с двумя блоками питания, с рейд контроллером для возможности горячей замены дисков, с bmc. Все остальное по потребностям в производительности.

Добавлю еще один важный момент. Если будете использовать объемные HDD диски (2+Tb), не собирайте raid5. В случае замены диска, массив очень долго перестраивается и есть большая вероятность сбоя второго диска. В этом случае вы теряете все данные. Я в основном использую raid1 или raid10, в том числе и для ssd. При этом часто вижу сопротивление отдельных лиц от рейда на ssd. Якобы это может снижать производительность. Я не вижу смысла спорить по этому поводу, потому что raid собирается для отказоустойчивости. Как ещё её можно относительно просто обеспечить? Даже не обсуждаю это. Для бэкапов, если на сервере 5 и более дисков, делаю raid6.

Выбор гипервизора

Дальше идет очень спорная тема - какой выбрать гипервизор. Я всегда, в обязательном порядке, всё настраиваю в виртуальных машинах. На железо ставится только гипервизор и больше ничего. Это позволяет полностью отвязаться от железа. Гипервизоров, к слову, обязательно должно быть два. Не важно, какое там будет железо, главное, у вас всегда должна быть возможность оперативно развернуть все сервисы на подменном железе, в случае выхода из строя основного.

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

Теперь, собственно, о гипервизорах. Я рассматриваю только бесплатные варианты, так как чаще всего потребности малого и среднего бизнеса могут быть удовлетворены бесплатными гипервизорами. Выбор состоит из следующих вариантов:

1. VMWare Esxi. Нормальный вариант от лидера отрасли. Одно время там были неприятные ограничения в бесплатной версии, но сейчас вроде бы нет этих проблем. Существенным минусом vmware я считаю невозможность установить её на софтовый рейд и отсутствие хороших инструментов для автоматических бэкапов. Если у вас нет железного рейд контроллера, то esxi вам не подойдет.
2. Hyper-V. Если не ошибаюсь, он второй по популярности и доле рынка гипервизоров. Вариант нормальный, встает на фейк рейды (не рекомендую на них ставить) и даже позволяет их мониторить. Я использую Hyper-V там, где предполагается эксплуатация виртуальных машин на базе Windows. Статья по настройке 2019-й версии - Установка и настройка Windows Hyper-V Server 2019. Существенный минус Hyper-V - не умеет пробрасывать usb в виртуальные машины. Если у вас usb токен, например, от лицензии 1С, это может стать проблемой. Решение может быть софтовое — usbipd-win. Ну а плюс это то, что под капотом привычный Windows Server.
3. KVM в составе ProxMox. Если посмотреть статистику по использованию гипервизора kvm, то окажется, что она ничтожно мала. Почему так, я не очень понимаю, ведь kvm использует огромное число хостеров для построения своей инфраструктуры. Она же в основе продукта Red Hat - RHEV. В общем случае я предпочитаю использовать proxmox. Он без проблем устанавливается на софтовый рейд mdadm. Его легко и быстро установить и настроить (по сравнению с hyper-v). У него удобный интерфейс управления через браузер. Из коробки присутствует инструмент для бэкапов, правда поддерживает только полные бэкапы виртуальных машин. Но есть отдельный продукт — Proxmox Backup Server, в котором есть уже и инкрементное хранение бэкапов. В других гипервизорах этот вопрос придется решать отдельно. Proxmox умеет пробрасывать usb в виртуальные машины. По моему мнению, на сегодняшний день по совокупности факторов этому продукту нет конкурентов в малом и среднем бизнесе.
4. XenServer. Раньше я активно использовал этот гипервизор. Нравилось то, что так же вставал на mdadm, под капотом centos, плюс удобная панель управления в виде приложения на Windows. Минус бесплатной версии xenserver, который доставал - за многими настройками приходилось лазить в консоль и писать километровые команды. Например, чтобы добавить виртуальную машину в автозагрузку. XenServer тоже позволяет пробрасывать usb виртуалкам. На тот момент, когда я им пользовался, была бесплатная утилита по бэкапу, поддерживающая дедупликацию и инкрементные live бэкапы. Потом ее сделали полностью платной. И одновременно с этим, 7-я версия XenServer перестала устанавливаться на mdadm. В итоге все его плюсы превратились в тыкву и я перестал его использовать. Сейчас есть более функциональный бесплатный аналог на основе гипервизора Xen — XCP-NG, но мне кажется, он уже не особо нужен на фоне Proxmox.

Вкратце всё расписал, что знал, по гипервизорам. Какой из них использовать — решать вам. Я остановился на proxmox и hyper-v. Как уже сказал ранее, важно ничего не ставить на сам гипервизор, чтобы не привязываться к железу и без проблем переезжать на другой гипервизор.

Почтовый сервер

По почтовому серверу у меня есть отдельная подробная статья с огромным количеством комментариев - выбор почтового сервера. Если решите использовать свой, то выбор, в основном будет стоять между самосбором на основе необходимых компонентов (postfix+dovecot), либо какого-то готового варианта, типа Zimbra (уже не сильно актуально из-за прекращения поддержки open source версии) или Iredmail. Платный вариант с Exchange я не рассматриваю. Если инфраструктура на Windows и есть деньги на Exchange, то имеет смысл использовать его.

В первом случае вы настроите только то, что вам реально нужно. Это снижает требование к железу, повышает надежность, упрощает дебаг, так как система более простая получается. Но и настроить всё это не просто. Почтовый сервер требует некоторого опыта в Linux и совсем новичкам дается не просто. Но зато вы получаете гибкость (перенос почтового сервера, защита почтового сервера) и возможность настроить некоторые нестандартные вещи (автозамена темы письма, запрет писем с поддельным полем from, очистка почтовой базы).

Готовая сборка в этом плане проще, так как быстрее ставится и имеет готовый интерфейс для управления. Но в замен вы теряете в гибкости. Плюс, вам будет трудно решать проблемы, если до этого с почтовыми серверами не работали. К примеру, мне сейчас всё равно, что использовать, хоть Zimbra, хоть Iredmail. Я и логи знаю где смотреть, и в базу могу залезть что-то глянуть, и бэкапы скриптами наколхозить если что. Иначе за них придется платить отдельные деньги.

В общем, по почтовому серверу резюме такое — если есть желание разбираться в этой теме, настраивайте сервер сами. Если просто нужна нормальная почта, а почтовыми серверами заниматься нет большого желания, ставьте какую-то сборку. Вот список наиболее популярных на сегодняшний день: Mail-in-a-Box, Mailcow, hMailServer, Tegu, Carbonio CE, Poste.io, Modoboa.

Файловый сервер для офиса

С файловыми серверами все просто. Если инфраструктура на Windows с AD и есть возможность поднять файловый сервер на Windows, поступите именно так. Это простой, удобный и надежный вариант. Из разряда настроил и забыл. Альтернатива - Samba, с AD или без.

В целом, интеграция Samba + AD работает. Но есть нюансы. Я за всю свою карьеру сталкивался с различными проблемами работы самбы. То права доступа к файлам слетают, то авторизация не работает, то еще какие-то проблемы. Все решаемо, но доставляет лишние хлопоты. У самбы ужасные логи, трудно дебажить. Если проблемы с авторизацией и вводом в домен, приходится практически вслепую исправлять ошибки, так как в логи неинформативны. При бэкапах и переносе сервера будет отдельно стоять вопрос сохранения прав доступа.

Если у вас нет AD, то никаких проблем не будет. Настраиваете Самбу, логирование доступа, корзину. Корзина для удаленных файлов особенно нравится. Если не ошибаюсь, для винды ее до сих пор не завезли.

Есть ещё вариант — установить готовую сборку под хранение файлов, типа Nextcloud. Это намного больше, чем просто файловый сервер, так что посмотрите предлагаемый функционал. Если он вам особо не нужен, то лучше настроить обычную самбу.

Для простого файлового сервера с доступом через браузер можно обратить внимание на File Browser. Простой в настройке и удобный в использовании файловый сервер. Более функциональный аналог — SFTPGo.

Выбор сервера телефонии

С выбором решения по VOIP для офиса вопросов много. Я не знаю, что тут однозначно посоветовать, так как мой опыт очень узок. Выбирать придется из следующего:

1. Ванильный Asterisk. Я всегда использовал его. Как обычно, основное преимущество - гибкость настроек, выбор подходящей операционной системы. Минус - сложно настраивать. Если не знакомы с астериском, просто так взять и въехать в тот же dialplan сходу не получится. У меня есть отличная статья по этой теме для новичков - настройка asterisk. Освоите голый астериск, все остальное будет значительно проще.
2. Freepbx. Это готовая панель управления на базе asterisk. Все управление происходит через веб интерфейс. В консоль сервера лазить не надо. Плюс тут очевиден - проще разобраться и быстрее настроить. Минус тоже закономерен - вы ограничены в функционале тем, что заложили в него разработчики панели. В целом, это нормальное решение, много где его видел, каких-то явных проблем не знаю. Более простые аналоги — MikoPBX, Issabel PBX.
3. Платное софтовое решение. Мне более ли менее известно 3cx. Сам его не настраивал, но видел компанию, где оно использовалось. Ничего конкретного сказать не могу, так как нет собственного опыта эксплуатации. Плохих отзывов не слышал. В целом, хорошее коробочное решение, которое можно установить на свое железо (это важно), в случае необходимости перенести.
4. Готовое аппаратное решение. Вы покупаете железку с готовым интерфейсом управления. Это может быть браузер, либо какая-то вендорская программа. Тут я тоже ничего не могу сказать конкретного, так как сам не эксплуатировал. У всех известных вендоров по телефонии есть решения на базе VOIP. Я немного сталкивался с телефонными станциями Siemens и Panasonic с платами расширения для VOIP. Мне не нравятся эти решения, так как привязаны к железу. Если обычную виртуалку с asterisk можно забэкапить и развернуть где угодно, то что делать с телефонной станцией в случае ее поломки?
5. Виртуальная АТС как услуга. Вы покупаете у облачного провайдера готовую услугу. Управляете ей через браузер. Свой сервер не нужен. Абонентские устройства сразу подключаются к облаку через интернет. Решение сейчас популярное и удобное, так как не требует начальных затрат и особой настройки. Покупается услуга, быстро настраивается и можно сразу пользоваться. Очевидных минусов тут два. Первое, вы регулярно платите абонентку за услугу, в то время как свой сервер условно бесплатен, если у вас им занимается сисадмин на полной ставке. Второе, без интернета у вас нет связи между сотрудниками офиса. Да и в целом, все локальное общение идет через интернет и зависит от него, что явно не удобно. Этот вариант однозначно подходит тем, у кого нет штатного сисадмина с подходящими компетенциями. Для всех остальных надо думать и взвешивать все варианты.

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

Выбор self-hosted чата

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

• Zulip
• Mattermost
• Matrix Synapse
• MyChat (сейчас не рекомендую, разработчик из Украины)

В этом списке не хватает еще одного бесплатного чата, который мне часто советовали попробовать - Rocket.Chat. Когда я его смотрел, он был похож на Mattermost, но это было очень давно. Сейчас они уже разошлись в разные стороны. В настоящее время у меня есть желание еще раз проработать этот вопрос. Попробовать все популярные чаты и что-то выбрать для использования.

Основная проблема со своим чат сервером в том, что ожидаешь функционала, к которому привык в популярных мессенджерах - Telegram, WhatsApp, Slack и т.д. Но по факту они намного хуже и нужно идти на какие-то компромиссы, а не хочется. Так что в настоящий момент я не могу посоветовать какой-то конкретный чат.

Вот ещё несколько вариантов бесплатных чатов, которые можно рассмотреть: Twake, Revolt, Delta Chat, Jami, SimpleX Chat.

Система мониторинга

С выбором системы мониторинга для своей инфраструктуры меньше всего вопросов и сомнений. Тут я однозначно рекомендую Zabbix. У меня очень много статей по этой теме. Если вы новичок, то начать стоит с подробной статьи по установке и начальной настройке. Далее можно добавить уведомления в Telegram.

Может возникнуть закономерный вопрос. А почему именно Zabbix в качестве системы мониторинга? Ведь сейчас очень популярен прометеус. Сравнение Zabbix vs Prometheus я сделал в отдельной статье. Все подробности там. Есть еще Nagios и Icinga. В целом, я знаком с ними, но как по мне, функционал сильно хуже по сравнению с Zabbix. Не вижу причин их использовать. Хотя недавно общался с человеком, который обслуживает мониторинг nagios на тысячи хостов. Для меня это было откровением, так как не думал, что ее используют в масштабных системах. Считал, что это больше для небольшой инфраструктуры, где не принципиально, что использовать.

Сбор и хранение логов

Для начала расскажу, зачем вообще хранить логи. В целом, в небольшой организации можно обойтись без централизованного хранения логов. Можно вручную проверять каждый лог по мере необходимости. Тем не менее, я обычно настраиваю единое хранилище. Из того, что регулярно будет требовать внимания — логи почтового сервера, в частности postfix и dovecot, логи asterisk и samba. Вам будет значительно проще находить нужную информацию из единой точки входа.

В самом простом варианте вы можете собрать все необходимые логи в текстовые файлы с помощью syslog-ng и просматривать их через webmin. Почему именно webmin? Мне лично нравится там просмотрщик текстовых логов. Удобно работает выборка и поиск. Именно такое решение я часто применял. Требует минимальных ресурсов на работу, плюс настраивается все очень просто и быстро.

Если вам нужно удобное хранилище логов с хорошим поиском, визуализацией, редактированием на лету и т.д., то конечно лучше использовать для этого ELK Stack. У меня много статей на тему сбора и визуализации информации из логов разных сервисов и устройств. Все это хранится в отдельном разделе. Выбирайте, что вам нужно и настраивайте. Но даже если вы просто соберете все логи в elasticsearch, без визуализации и настройки, это все равно значительно облегчит вам управление инфраструктурой. А если нужно проводить какой-то анализ происшествий, событий безопасности или сбоев, то без него вообще не обойтись.

Пример подбора серверов для офиса

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

Скачать таблицу.

При таком раскладе и один сервер сможет потянуть всю нагрузку, в случае аварии с другим. Если вам нужно сэкономить на лицензиях Windows Server, то понятно, что надо будет все компоновать поплотнее. В самом экономном варианте, на каждом гипервизоре будет по одному Windows Server. Само железо может быть очень бюджетным, если будет приобретаться б.у. Каждый сервер можно уложить в бюджет ~2,500$.

Советую не экономить на памяти. Она стоит не дорого, но очень упрощает жизнь. Чем больше, тем лучше. В общем случае, можно обойтись и без SSD. 1С, конечно, будет неспешно работать, но в целом жить можно. Так же не советую покупать дорогие процессоры. Зачастую они остаются недонагруженными, так что можно что-то попроще брать.

Бэкапы

Сервер бэкапов можно собрать на любом, в том числе десктопном, железе. На нем не будет ни нагрузки, ни жесткого требования к максимальному аптайму. Чаще всего он будет работать по ночам и забирать информацию с серверов. Но если есть возможность, лучше всё же какой-то простенький сервер, чтобы было удаленное управление через ipmi. Как правильно делать бэкапы я подробно рассказал, а так же объяснил отдельно, почему надо так же дублировать бэкапы куда-то вовне, если вы арендуете размещение своих серверов у какого-то хостера.

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

• Veeam Agent for Windows или Linux — известные бесплатные инструменты для бэкапа всей системы целиком или отдельных данных от одного из мировых лидеров в данной тематике.
• Kopia — кроссплатформенная система для бэкапа файлов (Win, Lin, Mac) c GUI. Может подключаться по ssh к хостам, поддерживает подключение к storage по S3,webdav, sftp. Простая и удобная система для тех, кто хочет всем управлять через GIU. В консоль лизить не обязательно.
• Burp — написан на C, использует как и rsync библиотеку librsync. Работает в режиме клиент - сервер. Умеет шифрование, дедупликацию, планировщик, оповещения и т.д. Облегченная версия Bacula/Bareos для тех, кто последнюю не осилил.
• Syncthing — утилита для синхронизации каталогов по сети, которая работает по принципу торрент клиентов. Можно автоматически синхронизировать данные в режиме реального времени на нескольких хостах. Важно понимать, что это не совсем программа для бэкапа, а скорее для копирования данных в режиме реального времени. А уже с копии можно спокойно снимать бэкап.
• Borgbackup — кроссплатформенная утилита для бэкапа, состоящая из одного бинарника. При этом имеет обширный функционал - дедупликация, сжатие и т.д. Работает по ssh, клиенты не нужны. Отлично подходит для использования в скриптах. Хранит данные в бинарном формате.
• Rsnapshot — написан на perl, под капотом обычный rsync. По сути это скрипт для автоматизации бэкапов с помощью rsync. Он умеет делать инкрементные бэкапы, ротировать их и чистить устаревшие данные. Для экономии места хранилища использует hard links на одни и те же файлы в бэкапах.
• BackupPC — полноценная кроссплатформенная система бэкапов со своим GUI. Работает по ssh, в том числе с помощью rsync. Подойдет для тех, кто не осилил или ему не нужен весь функционал Bacula/Bareos.
• FreeFileSync — это аналог известной платной программы под Windows GoodSync, которую многие знают, но она платная. Работает FreeFileSync примерно так же, только полностью бесплатна, исходный код открыт.

Более подробно все эти программы и некоторые другие описаны у меня в отдельной статье — Топ 12 бесплатных программ для бэкапа.

Заключение

Материал получился очень большим. Планировал сделать небольшую заметку, в итоге наполнял статью несколько дней. Собрал в ней всё, что вспомнил из своего опыта и то, что описывал на сайте и в telegram канале. Надеюсь, вам пригодится эта информация. Замечания, критику, пожелания жду в комментариях. Материал получился спорным, как ни крути.

И еще важное дополнение. Все описанное железо не обязательно размещать у себя. Его можно либо полностью арендовать, либо приобрести самостоятельно и разместить в ЦОД. Только выбирайте хостера правильно.

Помогла статья? Подписывайся на telegram канал автора