Как сделать бэкап домена
Резервное копирование контроллеров домена с помощью Veeam
Microsoft Active Directory является стандартом в инфраструктуре, где требуется аутентификация пользователей и централизованное управление. Почти невозможно представить себе, как системные администраторы справлялись бы со своей работой без этой технологии. Однако использование Active Directory не только приносит большую пользу, но и налагает большую ответственность, требуя значительного времени и понимания процессов работы. Поэтому я предлагаю вашему вниманию несколько cтатей, которые расскажут, как успешно выполнять бэкап и восстановление Active Directory с помощью решений Veeam. В частности, я поясню, как Veeam помогает делать копии контроллеров домена (DC) или отдельных объектов AD и при необходимости восстановить их.
А начну я с того, что в сегодняшнем посте расскажу о возможностях бэкапа физических и виртуальных контроллеров домена, предоставляемых Veeam, и о том, что необходимо помнить во время бэкапа. За подробностями — под кат.
Сервисы Active Directory разработаны с учетом избыточности, поэтому привычные правила и тактики бэкапа необходимо адаптировать соответствующим образом. В данном случае будет неправильно использовать ту же политику бэкапа, что уже работает для серверов SQL или Exchange. Вот несколько рекомендаций, которые могут помочь при разработке политики бэкапа для Active Directory:
Если у вас виртуальный DC
Так как сервисы Active Directory потребляют малую часть ресурсов системы, то контроллеры домена обычно становятся первыми кандидатами для виртуализации. Чтобы защитить виртуализованный контроллер с помощью Veeam, нужно установить и настроить Veeam Backup & Replication.
Важно! Решение работает с ВМ контроллера домена на Windows Server 2003 SP1 и выше, минимальный поддерживаемый функциональный уровень леса — Windows 2003. Учетной записи нужно предоставить права администратора Active Directory –— можно работать под учетной записью администратора предприятия или домена.
Процесс установки и настройки Veeam Backup & Replication уже неоднократно освещался – например, в видео, подготовленном системным инженером Veeam, поэтому обойдемся без подробностей. Предположим, что все настроено и готово к работе. Теперь нужно создать задание бэкапа контроллера домена. Процесс настройки довольно прост:
AAIP — технология Veeam, которая обеспечивает бэкап ВМ с учетом состояния приложений. Она выполняет поиск приложений гостевой ОС, сбор их метаданных, «заморозку» с помощью соответствующих механизмов (Microsoft VSS Writers), подготовку процедуры восстановления с использованием VSS для приложений, которая будет выполнена при первом запуске восстановленной ВМ, а также усечение журналов транзакций в случае успешного завершения бэкапа. Если функция AAIP не будет включена, гостевая ОС контроллера домена не поймет, что был выполнен ее бэкап и обеспечена защита. Поэтому через некоторое время вы можете обнаружить внутреннее предупреждение в журналах сервера Event ID 2089: backup latency interval (т.е. бэкап не выполнялся в течение интервала задержки архивации).
Если у вас физический DC
Честно говоря, я надеюсь, что вы идете в ногу со временем, и в вашей компании контроллеры домена давно виртуализованы. Если это не так, то надеюсь, что вы их регулярно обновляете и они работают на относительно современных версиях ОС Windows Server —Windows Server 2008 (R2) и выше. (О нюансах работы с более старыми системами будет отдельная статья).
Итак, у вас есть один или несколько физических контроллеров домена, работающих под Windows Server 2008 R2 и выше, и вы хотите их защитить. В этом случае вам потребуется Veeam Endpoint Backup — решение, предназначенное специально для защиты данных физических компьютеров и серверов. Veeam Endpoint Backup копирует нужные данные с физической машины и сохраняет их в файл резервной копии. В случае аварии вы сможете восстановить данные «на голое железо» или выполнить восстановление на уровне логического диска. Кроме того, вы сможете восстанавливать отдельные объекты с помощью Veeam Explorer для Microsoft Active Directory.
Примечание: чтобы выполнить установку в автоматическом режиме, используйте соответствующую инструкцию.
Примечание: Если в вашей среде уже установлен Veeam Backup & Replication, и вы хотите использовать существующий репозиторий Veeam для хранения резервных копий физических машин, вы можете перенастроить его прямо из Veeam Backup & Replication. Для этого на нужном репозитории щелкните правой кнопкой мыши, удерживая нажатой клавишу CTRL, и в открывшемся диалоге разрешите доступ к репозиторию, выбрав нужную опцию. При необходимости, там же включите шифрование, выбрав Encrypt backups stored in this repository.
Вот и все: бэкап выполнен, контроллер домена под защитой. Перейдите в репозиторий и найдите нужную резервную копию или цепочки резервных копий.
Если вы настроили репозиторий Veeam Backup & Replication в качестве целевого хранилища для резервных копий, то вновь созданные резервные копии будут отображаться в панели инфраструктуры Backups > Disk, пункт Endpoint Backups.
Вместо заключения
Разумеется, успешный бэкап — это хорошее начало, но далеко не все. Очевидно, что резервная копия ничего не стоит, если из нее нельзя восстановить данные. Поэтому в следующей статье я расскажу о различных сценариях восстановления Active Directory, включая восстановление контроллера домена, а также восстановление отдельных удаленных и измененных объектов с помощью собственных инструментов Microsoft и Veeam Explorer для Active Directory.
Восстановление контроллера домена из резервной копии с помощью Veeam
Продолжаем публикацию серии статей, написанных коллегой для корпоративного блога и посвященных резервному копированию и восстановлению контроллеров домена и собственно Active Directory.
В предыдущей статье из этой серии рассказывалось о процедуре бэкапе физических и виртуальных контроллеров домена (DC). Сегодня поговорим об их восстановлении.
Сразу скажу, что этот пост не является руководством по восстановлению Active Directory. Его задача — рассказать о том, что необходимо учитывать при восстановлении AD или конкретного контроллера домена из резервной копии, а также показать, как можно выполнить эти действия с помощью решений Veeam.
Доскональное знание своей инфраструктуры очень помогает при планировании восстановления AD. Вот лишь часть вопросов, ответы на которые вам необходимо знать, чтобы успешно восстанавливать данные:
Восстановление виртуализованного контроллера домена
Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим non-authoritative или потребуется воспользоваться режимом authoritative.
Разница между этими двумя режимами заключается в том, что при режиме восстановлении non-authoritative контроллер домена понимает, что он был в течение некоторого времени отключен. Поэтому он позволяет другим контроллерам обновить его базу данных, внеся в нее последние изменения, произошедшие во время его отсутствия. А при authoritative восстановлении контроллер считает, что только на нем имеется истинно верная база данных, поэтому именно он получает полномочия на обновление баз данных других контроллеров домена на основе своих данных.
В большинстве сценариев восстановления вам потребуется режим non-authoritative, поскольку в среде имеется несколько контроллеров домена. (Кроме того, authoritative восстановление может привести к новым проблемам.)
Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется non-authoritative восстановление, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров.
Чтобы выполнить authoritative восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые будут описаны позже.
Полезно: Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.
Восстановление в режиме «non-authoritative»
Итак, вернемся к файлам резервных копий, создание которых было описано в предыдущей статье. Для того, чтобы восстановить контроллер домена из резервной копии Veeam Backup & Replication, нужно:
Восстановление в режиме «authoritative»
С большой долей вероятности вам не потребуется этот режим восстановления. Однако давайте познакомимся с ним поближе, чтобы вы поняли, почему это так.
Этот режим можно использовать, например, когда вы пытаетесь восстановить верную копию контроллера домена в среде с несколькими контроллерами домена, при том, что вся структура AD по какой-то причине повреждена (напр., вредоносное ПО, вирус и т. п.). В этой ситуации, разумеется, предпочтительно, чтобы поврежденные котроллеры домена принимали изменения от вновь восстановленного контроллера.
Примечание: Выполняемые действия сходны с тем, что происходит при использовании Veeam SureBackup для восстановления контроллера домена в изолированной среде.
Чтобы выполнить восстановление удаленного объекта или контейнера в режиме authoritative и принудить контроллер домена скопировать восстановленные данные с этого DC на другие контроллеры:
Процедура authoritative восстановления SYSVOL (при использовании службы FRS):
Это обеспечит принудительное копирование данных на контроллеры домена, использующие старую технологию FRS, в «authoritative» режиме. Подробнее о восстановлении FRS можно почитать здесь.
Восстановление физического контроллера домена с Veeam Endpoint Backup
Теперь немного о восстановлении физической машины из резервной копии с помощью Veeam Endpoint Backup.
После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний Veeam будет полезна.
Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup более подробно.
Итак, мы рассмотрели восстановление отдельного контроллера домена. Однако чаще всего при работе с AD требуется восстановить случайно удаленный объект, и в этом случае восстанавливать контроллер целиком — не самый эффективный вариант. Поэтому в следующей статье я расскажу о восстановлении отдельных объектов каталога AD с помощью собственных инструментов Microsoft и утилиты Veeam Explorer для Active Directory.
Настраиваем резервное копирование контроллеров домена Active Directory
В этой статье мы поговорим об особенностях резервного копирования контроллеров домена Active Directory, рассмотрим, как настроить автоматическое резервное копирование AD с помощью PowerShell и встроенных средств Windows Server.
Нужно ли бэкапить Active Directory?
Не раз слышал от знакомых администраторов мысль, что если у тебя несколько (5, 10 и т.д.) территориально разнесенных контроллеров домена Active Directory, то бэкапать AD вообще не нужно, т.к. при нескольких DC вы уже обеспечили высокую отказоустойчивость домена. Ведь в такой схеме вероятность одновременного выхода из строя всех DC стремится к 0, а если один контроллер домена упал, то быстрее развернуть новый DC на площадке, а старый удалить с помощью ntdsutil.
Однако в своей практике я встречался с различными сценариями, когда все контроллеры домена оказались повреждёнными: в одном случае все контроллеры домена (а их было более 20 штук в разных городах) оказались зашифрованными из-за перехвата пароля домена шифровальщиком через утилиту mimikatz (для предотвращения таких схем см. статьи “Защита Windows от mimikatz” и “Защита привилегированных групп администраторов”), в другом случае домен положила репликация поврежденного файла NTDS.DIT.
В общем, бэкапить AD можно и нужно. Как минимум вы должны регулярно создавать резервные копии ключевых контроллеров доменов, владельцев ролей FSMO (Flexible single-master operations). Вы можете получить список контролеров домена с ролями FSMO командой:
Как проверить дату последнего бэкапа контроллера домена Active Directory?
Вы можете проверить, когда создавалась резервная копия текущего контроллера домена Active Directory с помощью утилиты repadmin:
В данном примере видно, что последний раз бэкап DC и разделов AD выполнялся 2017-02-18 18:01:32 (скорее всего он не делался с момента развертывания контроллера домена).
Вы можете получить статус по резервному копированию всех DC в домене командой:
Бэкап контроллера домена AD с помощью Windows Server Backup
Если у вас нет специального ПО для резервного копирования, вы можете использовать для создания резервных копий встроенный Windows Server Backup (этот компонент пришел на замену NTBackup). Вы можете настроить автоматическое задание резервного копирования в графическом интерфейсе Windows Server Backup, но у него будут ряд ограничений. Основной недостаток – новая резервная копия сервера всегда будет перезаписывать старую.
При создании резервной копии контроллера домена через WSB, вы создаете резервную копию Состояния системы (System State). В System State попадает база Active Directory (NTDS.DIT), объекты групповых политик, содержимое каталога SYSVOL, реестр, метаданные IIS, база AD CS, и другие системные файлы и ресурсы. Резервная копия создается через службу теневого копирования VSS.
Вы можете проверить, установлен ли компонент Windows Server Backup с помощью PowerShell командлета Get-WindowsFeature:
Если компонент WSB отсутствует, его можно установить с помощью PowerShell:
Add-Windowsfeature Windows-Server-Backup –Includeallsubfeature
Я буду сохранять бэкап данного контроллера домена AD в сетевую папку на отдельном выделенном сервере для резевного копирования. Например, путь к каталогу будет таким \\srvbak1\backup\dc01. Настроим NTFS разрешения на этой папке: предоставьте права чтения-записи в этот каталог только для Domain Admins и Domain Controllers.
Резервное копирование Active Directory с помощью PowerShell
Попробуем создать бэкап контроллера домена с помощью PowerShell. Для хранения нескольких уровней копий AD мы будем хранить каждый бэкап в отдельном каталоге с датой создания копии в качестве имени папки.
Запустите данный скрипт. Должна появится консоль wbadmin с информацией о процессе создании резервной (теневой) копии диска:
Я открыл журнал ошибок WSB — C:\Windows\Logs\WindowsServerBackup\Backup_Error-10-10-2019_08-30-24.log.
В файле содержится одна ошибка:
Забегая вперед, скажу, что проблема оказалась в некорректном пути в одном из драйверов VMWware Tools.
Чтобы исправить эту ошибку, откройте командную строку с правами администратора и выполните:
DiskShadow /L writers.txt
list writers detailed
После формирование списка наберите quit и откройте файл «C:\Windows\System32\writers.txt». Найдите в нем строку, содержащую “windows\\”.
В моем случае найденная строка выглядит так:
Как вы видите, используется неверный путь к драйверу VSOCK.SYS.
Чтобы исправить путь, откройте редактор реестра и перейдите в раздел HKLM\SYSTEM\CurrentControlSet\Services\vsock.
Измените значение ImagePath с
\systemroot\system32\DRIVERS\vsock.sys
на
System32\DRIVERS\vsock.sys
Запустите скрипт бэкапа еще раз.
Если бэкап выполнен успешно, в логе появятся сообщения:
Проверим даты последнего бэкапа на DC:
Теперь тут указано, что последний раз бэкап контроллера домена выполнялся сегодня.
На сервере резевного копирования размер каталога с резервной копией контроллера домена занимает около 9 Гб. По сути на выходе вы получили vhdx файл, который можно использовать для восстановления ОС через WSB, или вы можете вручную смонтировать vhdx файл и скопировать из него нужные файлы или папки.
Размер такого бэкапа будет составлять всего 50-500 Мб в зависимости от размера базы AD.
Для автоматического выполнения бэкапа, нужно на DC создать скрипт c:\ps\backup_ad.ps1. Этот скрипт нужно запускать по расписанию через Task Sheduler. Вы можете создать задание планировщика из графического интерфейса или из PowerShell. Главное требование — задание должно запускать от имени SYSTEM с включенной опцией Run with highest privileges. Для ежедневного бэкапа контролера домена AD создайте следующее задание:
Итак, мы настроили резевное копирование состояния AD, а в следующей статье мы поговорим о способах восстановления AD из имеющейся резервной копии контроллера домена.
Windows Server Backup: как создать резервную копию и восстановить данные с нее? Экономный бэкап
ОС Windows Server содержит средство резервного копирования, помогающее сэкономить на покупке стороннего программного продукта. Настройка Windows Server backup занимает минимум времени.
Установка средства, используемого для выполнения резервного копирования
Для установки Windows Server backup необходимо выполнить последовательно действия:
Рис. 1. Установка компонентов
Создание копии
Откройте Диспетчер серверов, из меню Средства выберите команду Система архивации данных Windows Server.
Рис. 2. Запуск средства резервного копирования
Основное окно средства копирования показано на рис. 3. На данный момент резервная копия не создавалась.
Рис. 3. Система архивации данных Windows Server
Выберите команду Расписание архивации (данная команда будет доступна на панели справа после перехода в раздел Локальная архивация на панели слева). Для настройки расписания в Windows Server backup следуйте следующим инструкциям:
Рис. 4. Конфигурация
Рис. 5. Время создания архива
Рис. 6. Где хранить копии?
Рис. 7. Выбор диска назначения
Рис. 8. Выберите диск и нажмите Далее.
После нажатия кнопки Готово, начнется форматирование диска для архивации. Нужно дождаться завершения этого процесса. Затем мастер сообщит вам время первой архивации. Нажмите кнопку Закрыть. Архивация успешно настроена.
Рис. 10. Форматирование диска для архивации
Бэкап файлов Windows-сервера своими руками
Здесь мы рассмотрим, как сделать систему дифференциального бэкапа «из коробки» (ну почти), с привлечением минимального количества внешних модулей, в лучших традициях UNIX-way.
Будем использовать 7za.exe \ 7z, а также UNIX-like утилиту pdate.exe, чтобы со временем нам было работать также удобно, как и в ламповом *NIX, а заменой bash нам будет «простонародный» BAT. Предыстория и подробности — под катом.
Предыстория
Все началось с истории про невнимательного и бесстрашного пользователя, открывающего приходящие по личной почте файлы откройменя.exe на рабочем компьютере. К сожалению, это оказалось не какой-нибудь посредственной малварью, а вполне обычным шифратором. Но, помимо файлов юзера, которые, конечно же, восстановлению не подлежат, оказалась задета одна крошечная, но важная шара, доступ к которой был у всех.
Взглянув на сие зашифрованное непотребство, я с благодарностью вспомнил про то, что каждый день у меня делается бэкап этой (и не только этой) шары встроенными средствами Windows Server 2003 SP2 x64. Но, полистав этот бэкап, я понял, что в плане резервного копирования средствами самой Windows не все так радужно. Во-первых, полный бэкап оказался недоступен, а значит восстановить cold-data (файлы, которые меняются очень редко) вряд ли получится. Во-вторых, восстановление из созданного инкрементального бэкапа оказалось задачей нетривиальной — за каждый шаг получалось восстановить только данные, которые были изменены, и ничего более. Получается, чтобы восстановить хотя бы все измененные данные (раз полный бэкап оказался утерян), то пришлось бы перебирать по очереди все бэкапы — не совсем то, что я ожидал от инкрементального бэкапа в таком случае.
Кто то из вас может сказать — надо было проверять работоспособность бэкапа, и да, так оно и есть. Но тот из вас, кто работает в торговле, может понять, куда может уходить время админа — да-да, они самые, онлайн-кассы.
Крепко задумавшись, я вспомнил свое первое знакомство с системой инкрементального копирования fsbackup за авторством Максима Чиркова www.opennet.ru/dev/fsbackup — гибкость, простота, в то же время обилие возможностей и открытый формат хранения архивов (tar). Жаль, что система разработана под *NIX / Linux. Google также не ответил на мой вопрос про подобную систему под Windows. Самое полезное, что я нашел — это краткий гайд хабровчанина antip0d и пример скрипта для резервного копирования. Именно материал по последней ссылке я и использовал для своего скрипта.
Собираем систему
В первую очередь, скачиваем последнюю стабильную версию. На момент написания это 16.04. Наш бэкап будем хранить в 7z архиве: поддержка многопоточности, шифрованных/многотомных архивов, а скорость извлечения из 7z выше скорости упаковки в 10-20 раз!
UPD: Спасибо хаброжителю Taciturn за поправку — вы также можете использовать 7z.exe, уже установленный в вашей системе. Функциональных различий между 7z и 7za я не выявил.
Нас интересуют:
7za.exe — автономная версия 7-Zip.
7za.dll — библиотека для работы с архивами 7z
7zxa.dll — библиотека для распаковки 7z архивов.
Для 64-битных ОС используем те же файлы из каталога x64.
К сожалению, ссылка из используемого мной материала на утилиту pdate никуда не ведет, единственная найденная мной версия
pdate v1.1 build 2007.12.06
© 2005-2007 Pavel Malakhov 24pm@mail.ru
К счастью, на том же ресурсе есть краткая статья по этой программе, там же ее можно скачать.
Мной была использована следующая структура каталогов:
D:\winfsbackup — корневая директория скрипта и связанных файлов
D:\winfsbackup\7z — библиотеки и исполняемый файл 7za
D:\winfsbackup\backup — место хранения бэкапов (можно переназначить путем правки переменных, как и любые другие используемые файлы)
D:\winfsbackup\lists — списки включаемых и исключаемых файлов. О них расскажу чуть позже
D:\winfsbackup\log — логи
D:\winfsbackup\pdate
D:\winfsbackup\tmp — устанавливает рабочий каталог для временного базового архива
D:\winfsbackup\winfsbackup.bat — сам скрипт.
Логика работы
250 Гб. Для моего файлообменника в 550 Гб с преобладанием мелких файлов скорость бэкапа оказалась неудовлетворительна (почти 55 часов). Справедливости ради стоит сказать, что это не может служить сколь нибудь достоверным замером производительности — в процессе бэкапа выяснилось, что некоторые файлы недоступны (привет chkdsk), а бэкап складывался в раздел удаленного сервера, который тоже был занят операциями дискового ввода-вывода.
Первые 2 условия включены по-умолчанию, и описывают полный бэкап раз месяц + дифференциальные бэкапы. Остальные условия альтернативны, то есть при включении одного нужно выключить другое, или изменить логику работы на свой вкус.
Переменные
dm, dw, wn — соответственно день месяца, день недели и номер недели (в численном выражении).
verboseLevel — режим «говорливости», выдает информацию о том, куда будет записываться архив, и прочее. Полезно, когда вносишь в структуру скрипта серьезные изменения.
tmpDir — место сохранения временного файла. По умолчанию, 7-Zip строит новый базовый файл архива в том же самом каталоге, где и старый базовый файл архива. Определяя этот ключ, вы можете установить рабочий каталог, где будет построен временный базовый файл архива. После того, как временный базовый файл архива построен, он копируется поверх первоначального; затем временный файл удаляется.
Дифференциальный бэкап
По умолчанию, в дифференциальный бэкап помещаются файлы, которых нет в базовом архиве, а также более новые файлы. При желании, это поведение можно изменить. Описания ключей есть в стандартном файле справки 7z.
У такого подхода есть свои плюсы (которые я уже успел оценить) — быстрота разворачивания из бэкапа. В случае полного восстановления разворачиваем последний (или любой другой) имеющийся дифференциальный бэкап, а затем — полный архив, отказываясь от перезаписи имеющихся файлов.
Некоторые опции командной строки
-bsp2 — выводит строку с прогрессом выполнения в STDERR. STDOUT 7z перенаправлен в лог, прогресс, естественно, туда не пишется. Эта команда выводит его в STDERR, для большей информативности.
-ssw — упаковывает файлы, открытые для записи другим приложением. Если этот ключ не установлен, 7-Zip не включает такие файлы в архив.
-ms=off — отключает создание solid-архивов. Качество сжатия при этом, конечно же, падает, однако есть весьма весомые плюсы — вы можете периодически обновлять данные базового архива чтобы уменьшить размер дифференциальный бэкапов, и так как архив не является целостным, не нужно будет его дополнительно «пережимать». Non-solid архив более стоек к повреждениям, и время извлечения из него происходит заметно быстрее.
Include / exclude листы
По умолчанию определено 2 типа списка — список включаемых файлов / директорий (include_general.txt), и 2 списка исключений (exclude_general.txt, exclude_regexp.txt).
Список включения также поддерживает UNC-пути. Для того, чтобы поместить файл / директорию в исключения, путь должен быть относительным.
Например, если директория для бэкапа E:\foo\bar, и мы хотим исключить вложенную директорию E:\foo\bar\somefolder, то в exclude_general.txt мы должны добавить bar\somefolder или bar\somefolder\
Путь без слэша в конце может относиться как к файлу, так и к директории.
В exclude_regexp.txt вносятся исключаемые по regexp файлы, которые просматриваются рекурсивно. * — последовательность произвольных символов,? — любой символ.
7-Zip не использует системный синтаксический анализатор подстановочных знаков, поэтому «любой файл» для 7 Zip это ‘*’, а ‘*.*’ — файл, имеющий расширение.
Ну и наконец, скрипт целиком:
Вместо окончания
Всегда есть люди, которые против подобных решений, и всеми руками-ногами «за» использование всяких акронисов и прочего «махрового энтерпрайза».
Я же считаю, что решение должно быть соразмерно поставленной задаче, а в моем случае задача — иметь в укромном месте резервную копию файлопомойки, которую можно быстро развернуть — именно этим меня и разочаровал ntbackup.
Собранный пример можно посмотреть на YandexDisk.
Там же — zip-архив для скачивания.
Конструктивная критика, советы, и тем более, тестирование — welcome!
Спасибо за внимание! Всем долгого аптайма, стабильного линка, и конечно, бэкапов под рукой.