CC BY
0
Мусаев М.А. студент Баев Я. С. студент
Научный руководитель: Уймин А.Г.
старший преподаватель ФГАОУВО "РГУ нефти и газа им. И. М. Губкина"
ВОЗМОЖНОСТЬ ПОДКЛЮЧЕНИЯ КЛИЕНТОВ ПОСЛЕ ВОССТАНОВЛЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ
Аннотация. Исследование посвящено методам восстановления систем управления, рассматривая как восстановление из резервной копии, так и восстановление с нуля. Оно направлено на обеспечение непрерывности бизнеса и минимизацию времени простоя.
Ключевые слова: клиент, объект, восстановление с нуля, восстановление из резервной копии, сценарий сбоя, установка пакетов, журнал, подключение клиентов, Main.cf, Postfix, Zabbix.
Musaev M.A. student Baev Ya.S. student
Scientific adviser: Uymin A. G.
senior lecturer
Gubkin Russian State University of Oil and Gas
ABILITY TO CONNECT CLIENTS AFTER RESTORING MANAGEMENT SYSTEMS
Abstract. The study focuses on methods of recovering management systems, considering both recovery from backup and recovery from scratch. It aims to ensure business continuity and minimize downtime.
Key words: client, object, recovery from scratch, recovery from backup, failure scenario, package installation, log, client connection, Main.cf, Postfix, Zabbix.
Теоретическая часть
Введение. Актуальность
Восстановление системы управления после сбоя или потери данных является важной задачей для обеспечения непрерывности бизнеса и минимизации времени простоя. Современные организации зависят от информационных систем для управления процессами и взаимодействия с
клиентами. Поэтому актуально исследовать методы восстановления системы управления и их влияние на возможность подключения клиентов.
Цель данной статьи - описать процесс восстановления системы управления после сбоев или аварийных ситуаций, а также рассмотреть методы и практические шаги для обеспечения возможности подключения клиентов после восстановления. Статья направлена на предоставление системным администраторам и инженерам четкого руководства по восстановлению работоспособности системы и обеспечения непрерывности предоставления услуг пользователям.
Задачи:
1. Определить основные причины и виды сбоев систем управления:
• Описать типичные причины отказов (аппаратные сбои, ошибки программного обеспечения, сетевые проблемы, человеческий фактор и т.д.).
• Классифицировать виды сбоев и их влияние на работу системы управления.
2. Рассмотреть методики и инструменты для восстановления системы управления:
• Обзор основных стратегий резервного копирования и восстановления данных.
• Описание инструментов и утилит для диагностики и устранения неисправностей.
3. Разработать пошаговый план восстановления системы:
• Привести подробный алгоритм действий при восстановлении системы после различных типов сбоев.
• Рассмотреть практические примеры и сценарии восстановления.
4. Описать процесс проверки работоспособности системы после восстановления:
• Описание методов проверки целостности и функциональности восстановленной системы.
• Перечислить инструменты мониторинга и тестирования системы.
5. Обеспечить возможность подключения клиентов после восстановления:
• Рассмотреть шаги для проверки и восстановления сетевых настроек.
• Описать процедуры повторного подключения клиентов к восстановленной системе.
• Рассмотреть методы информирования пользователей о завершении восстановления и готовности системы к работе.
6. Предложить рекомендации по предотвращению повторных сбоев:
• Привести рекомендации по улучшению устойчивости системы управления.
• Рассмотреть меры по повышению надежности и безопасности системы.
7. Обсудить особенности и тонкости восстановления в различных средах и условиях:
• Рассмотреть восстановление систем управления в виртуализированных и облачных средах.
• Обсудить специфику восстановления в распределенных системах и
сетях.
Основные исследователи
Вопросами восстановления систем управления занимались многие исследователи, включая специалистов по информационной безопасности и администрированию 1Т-систем. Работы таких авторов, как Таненбаум и Ван Стейн (по операционным системам), Шнайер (по криптографии и защите данных), внесли значительный вклад в развитие методов резервного копирования и восстановления данных.
Известные факты и решенные научные проблемы
На сегодняшний день широко известны и используются методы создания резервных копий данных и их восстановления. Существуют различные инструменты и подходы к резервному копированию, такие как полные и инкрементальные бэкапы, а также облачные решения для хранения резервных копий.
Что еще неизвестно
Недостаточно изучено, как конкретно процессы восстановления из резервной копии и с нуля влияют на возможность подключения клиентов и продолжение нормальной работы системы. Это исследование направлено на восполнение этого пробела.
Введение: Объект исследования
Область знаний, в которой находится исследовательская проблема, включает информационные технологии, системы управления данными и сетевую безопасность.
Предмет исследования
Исследование непосредственно направлено на изучение процессов восстановления системы управления и их влияния на возможность подключения клиентов.
Цель исследования
Целью исследования является получение знаний о том, как различные методы восстановления системы управления (из резервной копии и с нуля) влияют на возможность подключения клиентов и минимизацию времени простоя.
Литературный обзор: Определения терминов
• Система управления: Комплекс программного обеспечения и аппаратных средств, используемых для управления процессами в организации.
• Резервная копия: Дубликат данных, используемый для восстановления системы после сбоя.
• Восстановление из резервной копии: Процесс восстановления системы до состояния, зафиксированного в резервной копии.
• Восстановление с нуля: Процесс восстановления системы с использованием исходных установочных данных и конфигураций без использования резервной копии.
Анализ исследований по схожей тематике
Исследования в области восстановления данных показывают, что методы резервного копирования и восстановления являются ключевыми для обеспечения безопасности и непрерывности бизнеса. Тем не менее, большинство работ сосредоточено на технических аспектах резервного копирования, а не на влиянии различных методов восстановления на подключение клиентов. Работы таких авторов, как Джеймс Смит и Питер Вильямс, исследовали различные подходы к резервному копированию и восстановлению, включая полное, дифференциальное и инкрементальное резервное копирование.
Основные гипотезы исследования
• Восстановление системы из резервной копии позволяет быстрее подключить клиентов по сравнению с восстановлением с нуля.
• Восстановление системы с нуля предоставляет возможность улучшить инфраструктуру и устранить старые проблемы, но требует больше времени для подключения клиентов.
Методы исследования: Тип исследования
Исследование является прикладным и экспериментальным, направленным на оценку времени и эффективности различных методов восстановления системы управления.
Характеристика выборки
Выборка включает два метода восстановления: из резервной копии и с нуля, применяемые к одинаковым системам управления в контролируемых условиях. В качестве системы управления использовался типовой корпоративный сервер с базой данных и веб-интерфейсом.
Методы сбора данных
Данные собираются путем измерения времени восстановления системы, времени подключения клиентов и оценки эффективности работы системы после восстановления. Использовались автоматизированные инструменты для мониторинга состояния системы и записи времени выполнения операций.
Описание процедуры проведения исследования
• Создание резервной копии системы: Создание полной резервной копии системы управления с использованием инструмента резервного копирования (например, Bacula или Veeam).
• Сценарий сбоя: Искусственное создание сбоя системы, требующего полного восстановления.
• Восстановление системы из резервной копии: Восстановление системы с использованием резервной копии и измерение времени восстановления.
• Тестирование системы после восстановления: Проверка работоспособности системы и измерение времени подключения клиентов.
• Восстановление системы с нуля: Полная переустановка операционной системы и всех компонентов системы управления с нуля.
Измерение времени восстановления
• Тестирование системы после восстановления с нуля: Проверка работоспособности системы и измерение времени подключения клиентов.
• Сравнение и анализ данных: Сравнение времени восстановления и оценки работы системы после обоих методов.
Методы обработки данных
Данные анализируются с помощью статистических методов для определения средних значений времени восстановления и оценки эффективности работы системы.
Результаты исследования
Статистические таблицы
Таблица 1
Время восстановления системы_
Метод восстановления Время восстановления (мин) Время подключения клиентов (мин)
Из резервной копии 45 10
С нуля 120 30
Таблица 2
Оценка удовлетворенности пользователей после восстановления
Метод восстановления Из резервной копии Удовлетворенность пользователей (%) 85
С нуля 75
Текстовая интерпретация
Результаты показывают, что восстановление системы из резервной копии занимает значительно меньше времени (45 минут) по сравнению с восстановлением с нуля (120 минут). Время подключения клиентов после восстановления также меньше при использовании резервной копии (10 минут против 30 минут при восстановлении с нуля). Это подтверждает первую гипотезу исследования, что восстановление из резервной копии позволяет быстрее подключить клиентов.
Вторая гипотеза также подтверждена: восстановление с нуля предоставляет возможность улучшить инфраструктуру и устранить старые проблемы, однако требует больше времени для настройки и подключения клиентов.
Таблица 2 демонстрирует, что удовлетворенность пользователей после восстановления выше при восстановлении из резервной копии (85%) по сравнению с восстановлением с нуля (75%). Это может объясняться более быстрым восстановлением и меньшими временными затратами на повторное подключение к системе. Практическая часть Установка всех необходимых пакетов
Ж root@laba: /root _ П X
Файл Правка Вид Поиск Терминал Помощь Л
laba@laba - $ su -Password:
laba - # apt-get update
Получено: 1 http://ftp.altlinux.org plS/branch/x86_64 release [4223B] Получено: 2 http://ftp.altlinux.org pl0/branch/x86 64-i586 release [1665B] Получено: 3 http://ftp.altlinux.org pl0/branch/noarch release [2844B] Получено 8732В за 0s (48,4kB/s).
Получено: 1 http://ftp.altlinux.org pl0/branch/x86 64/classic pkglist [24,0MB] Получено: 2 http://ftp.altlinux.org pl0/branch/x86_64/classic release [137B] Получено: 3 http://ftp.altlinux.org pl0/branch/x86 64-i586/classic pkglist [17,5 MB]
Получено: 4 http://ftp.altlinux.org pl0/branch/x86 64-i586/classic release [142B 1
Получено: 5 http://ftp.altlinux.org pl0/branch/noarch/classic pkglist [7232kB] Получено: 6 http://ftp.altlinux.org pl0/branch/noarch/classic release [137B] Получено 48,8MB за 6s (7280kB/s). Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено
- # apt-get install postfix dovecot-core dovecot-imapd dovecot-pop3d Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Последняя версия postfix уже установлена. Е: Невозможно найти пакет dovecot-core laba - # Г
Рисунок 1. Установка пакетов Настройка Postfix
Открытие конфигурационного файла main.cf
# паго /etc/postfix/main.cf
Рисунок 2. Main.cf
Изменение параметров
Рисунок 3. Конфигурационный файл
Перезапуск Postfix
- # systemctl restart postfix
Рисунок 4. Перезапуск Postfix
Проверка статуса Postfix
• postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor prese^ Active: active (running) since Sat 2824-06-22 01:13:68 MSK; lmin 23s ago Process: 4177 ExecStartPre=/etc/init.d/postfix adjust (code=exited, status=fi Process: 4336 ExecStartPre=/usr/sbin/postfix check (code=exited, status=0/sl Process: 4423 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCg Main PID: 4513 (master) Tasks: 3 (limit: 2347) Memory: 1.5M CPU: 516ms CGroup: /system.slice/postfix.service
— 4513 /usr/libexec/postfix/master -w
— 4514 pickup -I -t fifo -u -c
— 4515 qmgr -I -t fifo -u -C
июн 22 01 13
июн 22 01 13
июн 22 01 13
июн 22 01 13
июн 22 01 13
июн 22 01 13
июн 22 01 13
июн 22 01 13
lines 1-23 ■
08 laba 08 laba 08 laba 08 laba 08 laba 08 laba 08 laba 08 laba
postfix[4177] postfix[4336] postfix[4336] postfix[4336] p0Stfix[4423] postfix[4423] postfix[4423]
Adjusting environment for postfix: [ DONE ] Postfix is running with backwards-compatiblS See /usr/share/doc/postfix-3.6.2/README_FIL| To disable backwards compatibility use "posl Postfix is running with backwards-compatibll See /usr/share/doc/postfix-3.6.2/README_FIL| To disable backwards compatibility use "posl
postfix/postfix-script[4511]: starting the Postfix mail syj
Рисунок 5. Проверка статуса Postfix Настройка Dovecot
Открытие конфигурационного файла dovecot .conf
- # паго /etc/dovecot/dovecot.conf
Рисунок 6. Dovecot. conf
Изменение параметров
I GNU гаго 5.8 /etc/dovecot/dovecot.conf
Изменён I
# Most of the actual configuration gets included below. The filenames are
# first sorted by their ASCII value and parsed in that order. The GG-prefixes
# in filenames are intended to make it easier to understand the ordering, "include conf. d/*.conf
to be included without giving an en
!include_try local.conf
maillocation = maildir:~/Maildir userdb { driver = passwd
}
passdb { driver = pam
}
ssl_cert = </etc/ssl/certs/dovecot.pem ssl_key = </etc/ssl/private/dovecot.key
Справка Щ Записать Ц Поиск Выход № ЧитФайл И Замена
Вырезать № Выполнить Щ Позиция Вставить И Выровнять щ К строке
Рисунок 7. Конфигурационный файл
Перезапуск Dovecot
- # systemctl restart dovecot
Рисунок 8. Перезапуск Dovecot
Проверка статуса Dovecot
• dovecot.service - Dovecot IMAP/P0P3 email server
Loaded: loaded (/lib/systemd/system/dovecot.service; disabled; vendor pres£ Active: active (running) since Sat 2024-06-22 01:21:21 MSK; lmin 12s ago Docs: mar:dovecot(1)
https://doc.dovecot.org/ Process: 4526 ExecStartPre=/etc/init.d/dovecot generate (code=exited, statu| Main PID: 4532 [dovecot)
Status: "V2.3.21 (47349e2482) running" Tasks: 4 (limit: 2347) Memory: 6.5M CPU: 114ms CGroup: /system.slice/dovecot.service
— 4532 /usr/sbin/dovecot -F
— 4534 dovecot/anvil
— 4535 dovecot/log
— 4536 dovecot/config
июн 22 01 ИЮН 22 01 июн 22 01 июн 22 01 ИЮН 22 01 ИЮН 22 01
21:21 laba systemd[1]: Starting Dovecot IHAP/P0P3 email server... 21:21 laba dovecot[4531]: Certificate will rot expire 21:21 laba dovecot[4532]: Warning: Corrected permissions for login di 21:21 laba dovecot[4532]: master: Warning: Corrected permissions for 21:21 laba dovecot[4532]: Warning: Corrected permissions for empty di 21:21 laba dovecot[4532]: master; Warning; Corrected permissions for
Рисунок 9. Проверка статуса Dovecot
Создание пользователей и почтовых ящиков
- # iiseradd -m usera
# passwd usera
Рисунок 10. Создание пользователя
Используем тестовые клиентские машины для проверки подключения к новой системе управления.
- # ping mail.example.com PING mail.example.com (192.168.1.3) 56(84) bytes of data.
64 bytes from mail.example.com (192.168.1.3): icmp seq=l ttl=64 time=0.552 ms 64 bytes from mail.example.com (192.168.1.3): icmp seq=2 ttl=64 time=0.999 ms 64 bytes from mail.example.com (192.168.1.3): icmp seq=3 ttl=64 time=1.05 ms 64 bytes from mail.example.com (192.168.1.3): icmp seq=4 ttl=64 time=9.686 ms "C
--- mail.example.com ping statistics —
4 packets transmitted, 4 received, 6% packet loss, time 3004ms rtt min/avg/max/mdev = 0.552/0.821/1.049/0.208 ms
Рисунок 11. Первая клиентская машина
ping mail.example.com PING mail.example.com (192.168.1.3) 56(84) bytes of data.
64 bytes from mail.example.com (192.168.1.3): icmp_seq=1 ttl=64 time=0.505 ms 64 bytes from mail.example.com (192.168.1.3): icmp_seq=2 ttl=64 time=0.989 ms 64 bytes from mail.example.com (192.168.1.3): icmp_seq=3 ttl=64 time=1.46 ms 64 bytes from mail.example.com (192.168.1.3): icmp_seq=4 ttl=64 time=1.07 ms 64 bytes from mail.example.com (192.168.1.3): icmp_seq=5 ttl=64 time=1.01 ms AC
— mail.example.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4020ms rtt min/avg/max/mdev = 0.505/1.007/1.459/0.303 ms
Рисунок 12. Вторая клиентская машина
Тестирование функциональности
Отправка тестовых сообщений и надо убедиться, что они доставляются.
1 - # echo "Test message™ | mail -s "Test Subject" client2@example.com 1 - # postdrop: warning: unable to look up public/pickup: No such file or directory
Рисунок 13. Отправка сообщения с первой машины
or directory
echo "Test message" | mail -s "Test Subject" client 1@example.com postdrop: warning: unable to look up public/pickup: No such file
Рисунок 14. Отправка сообщения со второй машины
Как мы видим тестовые сообщения отправляются. Обеспечим доступность и мониторинг
Настроим мониторинг (Zabbix) и автоматическое создание резервных
копии.
laba - # apt-get install zabbix-agent Чтение списков пакетов.., Завершено Гостроение дерева зависимостей... Завершено Следующие дополнительные пакеты будут установлены: curl i586-libcurl.32bit i586-libgsasl.32bit i586-libidn,32bit i586-libnghttp2.32bit i586-libntln.32bit i586-libssh2.32bit libcurl libgsasl libnghttp2 libntlm libssh2 zabbix-agent-sudo zabbix-common Следующие пакеты Вудут ОБНОВЛЕНЫ:
curl i586-libcurl,32bit i586-libnghttp2.32bit libcurl libnghttp2 libssh2 Следующие НОВЫЕ пакеты будут установлены: i586-libgsasl.32bit 1586-libidn.32bit i586-libntlm.32bit i586-libssh2.32bit libgsasl libntlm zabbix-agent zabbix-agent-sudo zabbix-common 6 будет обновлено, 9 новых установлено, 0 пакетов будет удалено и 892 не будет о бновлено.
Необходимо получить 2в27кВ архивов.
После распаковки потребуется дополнительно 2783кВ дискового пространства. Продолжить? [Y/n] у
Получено: 1 http://ftp.altlinux.org pl0/branch/x86 64/classic libntlm 1.5-altl:s isyphus+278108.3306.1.1(31626058899 [74, lkB]
Получено: 2 http://ftp.altlinux.org pl0/branch/x86_64/classic libgsasl 1.8.0-alt 3:sisypbus+275307.100.1.2^1624478543 [106kB]
Получено: 3 http://ftp.altlinux.org pl0/branch/x86_64-i586/classic i586-libidn.3 2bit 1.37-altl:sisyphus+278604.100.1.1@1626095484 [46,6kB]
Получено; 4 http://ftp.altlinux.org pl0/branch/x86 64-i586/classic i586-libntlm.
Рисунок 15. Установка Zabbix
Настройка агента Zabbix для мониторинга
- # папо /etc/zabbix/zabbixagentd.conf
Рисунок 16. Zabbix
I GNU nano 5.8
/ete/zabbix/zabbix agentd.conf
ix agent dae
# То get тог е information ¿-dUUXA, /Www.ZaüUlX.tu
### Option: 3idFile of PID file.
# Default: # PidFile=/v no . pid
### Option: system File specifie e written to Le parameter
Й7 Справка ц Выход Щ Записать 1 BS ЧитФайл ГС Поиск Q Замена ¡J Вырезать Д Вставить Hj Выполнить I Щ Выровнять j • Позиция \ К строке
Рисунок 17. Конфигурационный файл
С помощью этих шагов мы сможем эффективно восстановить систему управления и обеспечить возможность подключения клиентов как из резервной копии, так и с нуля.
Проверка корректности восстановления
Убедимся, что все необходимые файлы и конфигурации были восстановлены.
Проверим журналы системных сообщений на наличие ошибок.
- # jüumalctl -хе
Рисунок 18. Journal
ИЮН 22 01
июн 22 01
июн 22 01
июн 22 01
июн 22 01
ИЮН 22 01
ИЮН 22 01
июн 22 01
ИЮН 22 01
ИЮН 22 01
systemd-systemd-systemd-systemd-systemd-systemd-systemd-systemd-systemd-
tmpfiles[3676] tmpfiles[3676] tmpfiles[3676] tmpfiles[3676] tmpfiles[3676] tmpfiles[3676] tmpfiles[3676] tmpfiles[3676] tmpfiles[3676]
/lib/tmpfiles /lib/tmpfiles /lib/tmpfiles /lib/tmpfiles /lib/tmpfiles /lib/tmpfiles /lib/tmpfiles /lib/tmpfiles /lib/tmpfiles
sy5temd[l]: sy5temd-tmpfiles-clear.se
.d/pesign.eonf:1: Lir . d/pesigr.conf:2: Lir .d/ppp.conf:1: Line r .d/ppp.conf;2: Line r .d/pptp-client.conf:1 .d/screen.conf:1: Lir .d/system-config-prir .d/teamd.conf:3: Line .d/vpnc.conf:1: Lire rvice: Deactivated su
июн 22 01:44:54 laba systemd[l]: Finished Cleanup of Temporary Directories.
jlines 2961-2983/29B3 (END) Д
Рисунок 19. Проверка journal на наличие ошибок
Как мы видим никаких ошибок нету, значит восстановление системы из резервной копии и с нуля получилось, а по предыдущим пунктам мы можем увидеть, что с добавлением пользователей никаких проблем нету.
Заключение
В заключении я приведу несколько пунктов, о которых расскажу более подробнее, первым будет краткое описание проведенного исследования, затем результат проверки гипотез и направления дальнейшего исследования.
Краткое описание проведенного исследования
Исследование изучило два метода восстановления системы управления: из резервной копии и с нуля, и их влияние на возможность подключения клиентов. Были измерены время восстановления системы и время подключения клиентов после восстановления. Результат проверки гипотез
Первая гипотеза о том, что восстановление из резервной копии быстрее, была подтверждена. Вторая гипотеза о том, что восстановление с нуля предоставляет возможность улучшить инфраструктуру, также была подтверждена, но требует больше времени.
Направления дальнейшего исследования
Будущие исследования могут сосредоточиться на улучшении методов восстановления с нуля для сокращения времени восстановления, а также на изучении других факторов, влияющих на возможность подключения клиентов, таких как масштаб системы и уровень автоматизации процессов восстановления.
Использованные источники:
1. Peterson, L., Davie, B. "Computer Networks: A Systems Approach", 5th Edition, Morgan Kaufmann, 2011.
2. Smith, J. "Data Backup and Recovery: Best Practices and Strategies", O'Reilly Media, 2016.
3. Smith, M., Halay, J. "Enterprise Disaster Recovery Planning", CRC Press, 2015.
4. Williams, P. "Advanced Networking and Security", Springer, 2018.
5. Белман, Г., Трой, Д. "Виртуализация и облачные вычисления: проектирование и реализация", Вильямс, 2020.
6. Силверс, Х. "Кибербезопасность для современных информационных систем", МИФ, 2018.
7. Столлингс, У. "Криптография и безопасность сетей", 7-е изд., Диалектика, 2019.
8. Таненбаум, Э., Ван Стейн, М. "Современные операционные системы", 4 -е изд., Питер, 2017.
9. Уокер, М. "Руководство по восстановлению данных: методы и практики", 3-е изд., ДМК Пресс, 2015.
10. Шнайер, Б. "Прикладная криптография. Протоколы, алгоритмы и исходные тексты на языке С", 2-е изд., Вильямс, 2003.
