Серверы, хранение и резервное копирование для офиса

Мы рассматриваем сервер, хранилище и резервное копирование как одну задачу. Если настроить только доступ к папкам, но не продумать копии, получается удобная единая точка отказа. Если настроить бэкап, но ни разу не проверить восстановление, наличие копии ещё не означает, что она спасёт данные.

Сначала фиксируем, какие данные действительно важны для работы.

Это могут быть:

• общие папки отдела;

• бухгалтерские документы;

• базы и файлы прикладных программ;

• рабочие проекты;

• сканы и договоры;

• архивы сотрудников;

• данные, которые сейчас разбросаны по локальным компьютерам;

• файлы, к которым нужен доступ нескольким пользователям.

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

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

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

Например:

• сотрудникам нужны общие папки с разграничением доступа;

• важные данные нельзя оставлять только на рабочих ПК;

• необходимо централизованно хранить документы и архивы;

• требуется единое место для резервных копий;

• есть программа или база, которая должна быть доступна нескольким сотрудникам;

• нужно отделить рабочие данные от пользовательских компьютеров;

• необходимо контролировать, кто имеет доступ к конкретным каталогам.

Для небольшой организации это не обязательно означает отдельный сервер в стойке. В зависимости от задачи достаточно NAS, существующего компьютера с корректно организованным хранением, виртуальной машины или облачного ресурса.

Мы не начинаем с выбора железа. Сначала определяем роль узла, нагрузку и последствия его отказа.

Универсального варианта нет.

NAS

NAS подходит, когда основная задача — общие файлы, архив и резервное копирование. Его проще обслуживать, чем полноценный сервер, но он тоже требует правильной настройки пользователей, прав, обновлений, дисков и копий.

RAID в NAS уменьшает риск простоя при отказе отдельного диска, но не является резервной копией. Удалённый файл, повреждённая база, ошибка пользователя или шифровальщик могут затронуть весь массив.

Отдельный сервер

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

Здесь важно считать не только объём дисков. Проверяются память, дисковая подсистема, сеть, резерв питания, возможность восстановления и дальнейшего обслуживания.

Облако

Облачное хранение полезно как независимая площадка и как часть резервной схемы. Но переносить туда всё автоматически тоже не всегда разумно: учитываются объём данных, скорость канала, время восстановления, права доступа и то, насколько бизнес зависит от интернета.

На практике часто лучше работает комбинация: рабочие данные локально, независимая копия — на другой площадке или в облаке.

Фраза «бэкап делается каждый день» сама по себе мало что говорит.

У рабочей схемы должны быть ответы как минимум на пять вопросов:

1. Что именно копируется?

2. Куда уходит копия?

3. Сколько версий хранится?

4. Что произойдёт, если исходная система недоступна?

5. Проверяли ли восстановление?

Особенно важно различать копию и синхронизацию.

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

Для важных данных полезен принцип 3-2-1:

• несколько экземпляров данных;

• хранение не на одном носителе или в одной системе;

• хотя бы одна копия отделена от основной площадки.

Но сама цифра ничего не гарантирует. Три копии, доступные из одной учётной записи и находящиеся в одной сети, могут потеряться одновременно.

При проектировании смотрим не количество копий, а независимость отказов: что будет при поломке диска, ошибке администратора, заражении, краже оборудования, пожаре, недоступности интернета или компрометации учётной записи.

Если сервер или NAS уже работает, начинать с замены оборудования обычно рано.

Сначала проверяем:

• фактический объём рабочих данных;

• свободное место и темп его расходования;

• состояние дисков и массива;

• кто имеет административный доступ;

• права пользователей на общие папки;

• наличие устаревших или общих учётных записей;

• куда выполняются резервные копии;

• глубину хранения версий;

• журнал успешных и неуспешных заданий;

• доступность копий при отказе основного узла;

• возможность восстановить отдельный файл и весь критичный набор данных;

• загрузку сети при копировании;

• зависимость от одного компьютера, диска, провайдера или пароля.

После такой проверки становится понятно, требуется ли новое оборудование или проблему можно решить настройкой существующего.

Сбой резервного задания обычно обнаруживается слишком поздно — когда копия уже понадобилась.

Поэтому после настройки мы считаем результатом не сообщение «Backup completed», а фактическое восстановление тестовых данных.

Для файлового хранилища проверяем, что можно:

• найти нужную дату;

• восстановить отдельный файл;

• вернуть папку с сохранением структуры;

• прочитать восстановленные данные;

• выполнить процедуру не только из работающего основного сервера.

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

Если появились ошибки диска, пропадают общие папки, система зависает или массив перешёл в аварийное состояние, первое действие — не «починить RAID любой ценой».

Сначала оценивается состояние данных и наличие независимой копии.

Опасные действия в такой ситуации:

• многократные перезагрузки без понимания причины;

• принудительная инициализация массива;

• замена сразу нескольких дисков;

• создание нового массива поверх старой конфигурации;

• запуск тяжёлых проверок на деградирующих дисках без копии;

• установка обновлений до сохранения критичных данных.

Если данные важнее самого сервера, приоритет — не вернуть оборудование в зелёный статус, а сохранить возможность восстановления.

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

Это удобно только до первого ошибочного удаления или инцидента.

Нормальная структура строится вокруг ролей:

• бухгалтерия видит бухгалтерские данные;

• сотрудники отдела — свои рабочие каталоги;

• руководитель получает необходимый уровень доступа;

• административные права не используются для повседневной работы;

• уволенный сотрудник не должен сохранять действующий доступ.

При этом права не должны быть настолько сложными, чтобы через полгода никто не понимал, почему пользователь не может открыть свой файл.

Сервер или NAS может быть исправен, но данные всё равно становятся недоступны из-за внешней инфраструктуры.

Проверяем:

• питание самого узла;

• коммутатор, через который к нему подключаются пользователи;

• корректное завершение работы при длительном отключении электричества;

• состояние ИБП, если он используется;

• сетевые подключения;

• место установки и охлаждение.

Нет смысла защищать сервер ИБП, если коммутатор с единственным сетевым подключением остаётся без питания.

После работ владелец не должен получать «коробку, которую лучше не трогать».

Должно быть понятно:

• где находятся рабочие данные;

• какие данные считаются критичными;

• кто и к чему имеет доступ;

• что именно резервируется;

• где находятся резервные копии;

• сколько версий хранится;

• как проверить успешность копирования;

• как восстановить файл;

• что делать при отказе основного оборудования;

• какие учётные данные и доступы нужно хранить у владельца.

Если система зависит от конкретного специалиста, который единственный знает пароль и схему, это уже риск.

Не каждое обращение заканчивается покупкой нового NAS или сервера.

Иногда проблема решается иначе:

• убрать хранение критичных файлов с одного рабочего компьютера;

• создать отдельные учётные записи;

• пересобрать права на папки;

• включить историю версий;

• настроить независимую резервную копию;

• заменить деградирующий диск;

• разделить рабочее хранилище и бэкап;

• проверить восстановление;

• документировать доступы и порядок действий при сбое.

Цель — не сделать инфраструктуру сложнее. Цель — чтобы данные оставались доступными в штатной работе и восстанавливаемыми после ошибки или отказа.

Стоимость — по задаче.

Она зависит от существующей инфраструктуры, объёма данных, числа пользователей, типа хранения, требований к резервному копированию и того, требуется ли новое оборудование.

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