По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Утилита Linux fsck (File System Consistency Check - проверка согласованности файловой системы) проверяет файловые системы на наличие ошибок или нерешенных проблем. Инструмент используется для исправления потенциальных ошибок и создания отчетов.
Эта утилита по умолчанию входит в состав дистрибутивов Linux. Для использования fsck не требуется никаких специальных шагов или процедуры установки. После загрузки терминала вы готовы использовать функции инструмента.
Следуйте этому руководству, чтобы узнать, как использовать fsck для проверки и восстановления файловой системы на Linux-машине. В руководстве будут перечислены примеры того, как использовать инструмент и для каких вариантов использования.
Когда использовать fsck в Linux
Инструмент fsck можно использовать в различных ситуациях:
Используйте fsck для запуска проверки файловой системы в качестве профилактического обслуживания или при возникновении проблемы с вашей системой.
Одна из распространенных проблем, которые может диагностировать fsck, - это когда система не загружается.
Другой - когда вы получаете ошибку ввода/вывода, когда файлы в вашей системе становятся поврежденными.
Вы также можете использовать утилиту fsck для проверки состояния внешних накопителей, таких как SD-карты или USB-накопители.
Базовый синтаксис fsck
Базовый синтаксис утилиты fsck следует этому шаблону:
fsck <options> <filesystem>
В приведенном выше примере файловой системой может быть устройство, раздел, точка монтирования и так далее. Вы также можете использовать параметры, относящиеся к файловой системе, в конце команды.
Как проверить и восстановить файловую систему
Перед проверкой и восстановлением файловой системы необходимо выполнить несколько шагов. Вам нужно найти устройство и размонтировать его.
Просмотр подключенных дисков и разделов
Чтобы просмотреть все подключенные устройства в вашей системе и проверить расположение диска, используйте один из доступных инструментов в Linux.
Один из способов найти диск, который вы хотите просканировать, - это перечислить диски файловой системы с помощью команды df:
df -h
Инструмент показывает использование данных в вашей системе и файловых системах. Обратите внимание на диск, который вы хотите проверить, с помощью команды fsck.
Например, для просмотра разделов вашего первого диска используйте следующую команду:
sudo parted /dev/sda 'print'
sda - это то, как Linux относится к вашему первому SCSI-диску. Если у вас два, вторым будет sdb и так далее.
В нашем примере мы получили один результат, поскольку на этой виртуальной машине был только один раздел. Вы получите больше результатов, если у вас будет больше разделов.
Имя диска здесь /dev/sda, а затем количество разделов отображается в столбце Number. В нашем случае это один: sda1.
Размонтировать диск
Прежде чем вы сможете запустить проверку диска с помощью fsck, вам необходимо отключить диск или раздел. Если вы попытаетесь запустить fsck на смонтированном диске или разделе, вы получите предупреждение:
Обязательно выполните команду размонтирования:
sudo umount /dev/sdb
Замените /dev/sdb устройством, которое вы хотите размонтировать.
Обратите внимание, что вы не можете размонтировать корневые файловые системы. Следовательно, теперь fsck нельзя использовать на работающей машине. Подробнее об этом в конце руководства.
Запустить fsck для проверки ошибок
Теперь, когда вы отключили диск, вы можете запустить fsck. Чтобы проверить второй диск, введите:
sudo fsck /dev/sdb
В приведенном выше примере показан результат для чистого диска. Если на вашем диске имеется несколько проблем, для каждой из них появляется запрос, в котором вы должны подтвердить действие.
Код выхода, который возвращает утилита fsck, представляет собой сумму этих состояний:
Смонтировать диск
Когда вы закончите проверку и ремонт устройства, смонтируйте диск, чтобы вы могли использовать его снова.
В нашем случае мы перемонтируем SDB-диск:
mount /dev/sdb
Сделать пробный запуск с fsck
Перед выполнением проверки в реальном времени вы можете выполнить тестовый запуск с помощью fsck. Передайте параметр -N команде fsck, чтобы выполнить тест:
sudo fsck -N /dev/sdb
На выходе печатается, что могло бы произойти, но не выполняется никаких действий.
Автоматическое исправление обнаруженных ошибок с помощью fsck
Чтобы попытаться устранить потенциальные проблемы без каких-либо запросов, передайте параметр -y команде fsck.
sudo fsck -y / dev / sdb
Таким образом, вы говорите «да, попытайтесь исправить все обнаруженные ошибки» без необходимости каждый раз получать запрос.
Если ошибок не обнаружено, результат будет таким же, как и без опции -y.
Пропускать восстановление, но выводить ошибки fsck на выходе
Используйте параметр -n, если вы хотите проверить потенциальные ошибки в файловой системе, не исправляя их.
У нас есть второй диск sdb с некоторыми ошибками журнала. Флаг -n печатает ошибку, не исправляя ее:
sudo fsck -n /dev/sdb
Заставить fsck выполнить проверку файловой системы
Когда вы выполняете fsck на чистом устройстве, инструмент пропускает проверку файловой системы. Если вы хотите принудительно проверить файловую систему, используйте параметр -f.Например:
sudo fsck -f /dev/sdb
При сканировании будут выполнены все пять проверок для поиска повреждений, даже если будет обнаружено, что проблем нет.
Запустить fsck сразу для всех файловых систем
Если вы хотите выполнить проверку всех файловых систем с помощью fsck за один раз, передайте флаг -A. Эта опция будет проходить через файл etc/fstab за один проход.
Поскольку корневые файловые системы нельзя размонтировать на работающей машине, добавьте параметр -R, чтобы пропустить их:
fsck -AR
Чтобы избежать запросов, добавьте параметр -y, о котором мы говорили.
Пропустить проверку fsck в определенной файловой системе
Если вы хотите, чтобы fsck пропустил проверку файловой системы, вам нужно добавить -t и no перед файловой системой.
Например, чтобы пропустить файловую систему ext3, выполните эту команду:
sudo fsck -AR -t noext3 -y
Мы добавили -y, чтобы пропускать запросы.
Пропустить Fsck в подключенных файловых системах
Чтобы убедиться, что вы не пытаетесь запустить fsck на смонтированной файловой системе, добавьте параметр -M. Этот флаг указывает инструменту fsck пропускать любые смонтированные файловые системы.
Чтобы показать вам разницу, мы запустим fsck на sdb, пока он смонтирован, а затем, когда мы его размонтируем.
sudo fsck -M /dev/sdb
Пока sdb смонтирован, инструмент выходит без проверки. Затем мы размонтируем sdb и снова запускаем ту же команду. На этот раз fsck проверяет диск и сообщает, что он чистый или с ошибками.
Примечание. Чтобы удалить первую строку заголовка инструмента fsck «fsck from util-linux 2.31.1», используйте параметр -T.
Запустить fsck в корневом разделе Linux
Как мы уже упоминали, fsck не может проверить корневые разделы на работающей машине, поскольку они смонтированы и используются. Однако даже корневые разделы Linux можно проверить, если вы загрузитесь в режиме восстановления и запустите проверку fsck:
1. Для этого включите или перезагрузите компьютер через графический интерфейс или с помощью терминала:
sudo reboot
2. Нажмите и удерживайте клавишу Shift во время загрузки. Появится меню GNU GRUB.
3. Выберите Advanced options for Ubuntu (Дополнительные параметры для Ubuntu).
4. Затем выберите запись с (recovery mode - режим восстановления) в конце. Подождите, пока система загрузится в меню восстановления.
5. Выберите fsck в меню.
6. Подтвердите, выбрав Yes в ответ на запрос.
7. По завершении выберите resume в меню восстановления, чтобы загрузить машину.
Что делать, если fsck прерывается?
Вам не следует прерывать работу инструмента fsck, пока он работает. Однако, если процесс будет прерван, fsck завершит текущую проверку, а затем остановится.
Если утилита обнаружила ошибку во время проверки, она не будет пытаться что-либо исправить, если ее прервать. Вы можете повторно запустить проверку в следующий раз и дождаться ее завершения.
Обзор параметров команды Linux fsck
Подводя итоги, ниже приведен список параметров, которые вы можете использовать с утилитой fsck Linux.
-а - Попробует автоматически исправить ошибки файловой системы. Подсказок не будет, поэтому используйте его с осторожностью.
-А - Проверяет все файловые системы, перечисленные в /etc/fstab.
-C - Показать прогресс для файловых систем ext2 и ext3.
-f - Заставляет fsck проверить файловую систему. Инструмент проверяет, даже если файловая система кажется чистой.
-l - Заблокирует устройство, чтобы другие программы не могли использовать раздел во время сканирования и восстановления.
-M - Не проверяет смонтированные файловые системы. Инструмент возвращает код выхода 0, когда файловая система смонтирована.
-N - Делает пробный запуск. В выводе печатается, что fsck будет делать без выполнения каких-либо действий. Также печатаются предупреждения или сообщения об ошибках.
-П - Используется для параллельного сканирования нескольких файловых систем. Это может вызвать проблемы, в зависимости от ваших настроек. Используйте с осторожностью.
-Р - Сообщает инструменту fsck, чтобы он не проверял корневые файловые системы при использовании параметра -A.
-р - Распечатать статистику устройства.
-t - Укажите типы файловых систем для проверки с помощью fsck. Обратитесь к странице руководства для получения подробной информации.
-T - Скрыть заголовок при запуске инструмента.
-у - Попытается автоматически исправить ошибки файловой системы во время проверки.
-V - Подробный вывод.
Одной из важнейших потребностей системы Linux является постоянное обновление последних исправлений безопасности, доступных для соответствующего дистрибутива.
В этой статье мы объясним, как настроить систему Debian и Ubuntu для автоматической установки и обновления необходимых пакетов безопасности или исправлений при необходимости.
Для выполнения задач, описанных в этой статье, вам понадобятся права суперпользователя.
Настройка автоматических обновлений безопасности в Debian и Ubuntu
Для начала установите следующие пакеты:
# aptitude update -y && aptitude install unattended-upgrades apt-listchanges -y
где apt-listchanges сообщит, что было изменено во время обновления.
Кстати, у нас есть статья, как сделать автоматическое обновление пакетов безопасности на CentOS или RHEL
Затем откройте /etc/apt/apt.conf.d/50unattended-upgrades в текстовом редакторе и добавьте эту строку в блок Unattended-Upgrade :: Origins-Pattern :
Unattended-Upgrade::Mail "root";
Наконец, используйте следующую команду для создания и заполнения необходимого файла конфигурации /etc/apt/apt.conf.d/20auto-upgrades для активации автоматических обновлений:
# dpkg-reconfigure -plow unattended-upgrades
Выберите Yes, когда будет предложено установить автоматические обновления (Automatically download and install stable updates? ) и затем убедитесь, что следующие две строки были добавлены в /etc/apt/apt.conf.d/20auto-upgrades:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
И добавьте эту строку, чтобы сделать отчеты подробными:
APT::Periodic::Verbose "2";
Наконец, проверьте /etc/apt/listchanges.conf, чтобы убедиться, что уведомления будут отправлены в root.
email_address=root
Готово! В этой статье мы объяснили, как обеспечить регулярное обновление вашей системы последними обновлениями безопасности. Кроме того, вы узнали, как настроить уведомления, чтобы держать себя в курсе, когда применяются исправления.
Графический интерфейс Cisco Unified Communications Manager (CUCM) имеет раздел Disaster Recovery System (DRS), который предназначен для проведения резервного копирования (backup) и восстановления системы (restore). Но бывают ситуации, когда GUI недоступен, например, из-за проблем с сетью. В этом случае, провести процедуры бэкапирования и восстановления можно через консоль CLI и сейчас мы расскажем как это сделать.
Процедура бэкапа
Перед началом процедуры, у вас должен быть настрое SFTP сервер, куда вы будете заливать бэкап с CUCM.
Для начала нужно добавить сервер, куда мы будем загружать бэкап. Для этого вводим команду:
utils disaster_recovery device add network [number of backups]
Где:
backup device name - Имя устройства, куда будем заливать бэкап;
path - Путь, куда будем заливать бэкап на данном устройстве;
ip-address of remote server - IP адрес удалённого устройства;
username - Имя пользователя;
number of backups - Количество резервных копий
После ввода данной команды, вас попросят ввести пароль пользователя, из под которым вы хотите осуществить бэкап (в нашем случае - ccmadmin)
admin: utils disaster_recovery device add network merionbckp ./ 10.20.30.123 ccmadmin
Please enter password to connect to network server 10.20.30.123:****
drfCliMsg: Backup Device has been saved successfully.
Проверим, что устройство для бэкапа успешно добавилось, для этого введём команду:
utils disaster_recovery device list
В выводе мы должны увидеть устройство, добавленное ранее:
admin:utils disaster_recovery device list
Device Name Device Type Device Path
--------------------------------------------------------------
merionbckp NETWORK ./
Волшебно! Теперь мы можем осуществить бэкап. Для этого пишем в консоли:
utils disaster_recovery backup network
Где:
backup device name - Имя устройства, куда будем заливать бэкап;
featurelist - Список функционала, который нужно забэкапить;
Для того, чтобы посмотреть какой функционал доступен для бэкапирования наберите команду: utils disaster_recovery show_registration , где servername - имя сервера, на котором осуществляется бэкап.
admin:utils disaster_recovery backup network UCM,CDR_CAR,PLM merionbckp
drfCliMsg: Backup initiated successfully. Please run 'utils disaster_recovery status backup' command to see the status
Всё, бэкап запущен! Чтобы проверить статус, нам предлагают ввести: utils disaster_recovery status backup
admin:utils disaster_recovery status backup
Status: SUCCESS :Backup Completed...
Tar Filename: 2019-02-16-04-21-37.tar
Storage Location: NETWORK
Operation: backup
Percentage Complete: 100
PLM CCM01 ELM-AGENT SUCCESS Sat Feb 16 04:17:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-agent.log
PLM CCM01 ELM-SERVER SUCCESS Sat Feb 16 04:17:26 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-server.log
CDR_CAR CCM01 CAR SUCCESS Sat Feb 16 04:17:27 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_cdr_car_car.log
UCM CCM01 BAT SUCCESS Sat Feb 16 04:19:23 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_bat.log
UCM CCM01 CCMPREFS SUCCESS Sat Feb 16 04:19:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmprefs.log
UCM CCM01 PLATFORM SUCCESS Sat Feb 16 04:19:30 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_platform.log
UCM CCM01 TCT SUCCESS Sat Feb 16 04:19:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tct.log
UCM CCM01 SYSLOGAGT SUCCESS Sat Feb 16 04:19:35 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_syslogagt.log
UCM CCM01 CDPAGT SUCCESS Sat Feb 16 04:19:36 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_CCM01_ucm_cdpagt.log
UCM CCM01 CLM SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_clm.log
UCM CCM01 CCMDB SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmdb.log
UCM CCM01 TFTP SUCCESS Sat Feb 16 04:21:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tftp.log
UCM CCM01 ANN SUCCESS Sat Feb 16 04:21:33 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ann.log
UCM CCM01 MOH SUCCESS Sat Feb 16 04:21:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ccm01_ucm_moh.log
Всё, бэкап готов!
Процедура восстановления
Чтобы восстановить конфигурацию CUCM из бэкапа, нужно сначала посмотреть – что доступно для восстановления на удалённом сервере? Проверить это можно командой:
admin:utils disaster_recovery show_backupfiles merionbckp
2019-02-16-04-21-37
2018-12-25-21-52-19
Выбираем нужный нам бэкап и вводим следующую команду:
admin:utils disaster_recovery restore network 10.20.30.123 2019-02-16-04-21-37 merionbckp
drfCliMsg: WARNING! There are nodes in current production cluster but NOT present in the backup. These nodes will be removed if you restore the Publisher. If you want to keep these nodes, you will need to manually re-add them after the restore.
Do you want DRS to perform a SHA-1 File Integrity Check of your backup archives y/n ?(n) : y
Please enter the comma seperated features you wish to restore. Valid features for server CCM01 are PLM,CDR_CAR,UCM:PLM,CDR_CAR,UCM
Do you want to restore database from the subscriber y/n ?(n) : n
drfCliMsg: Restore initiated successfully. Please run 'utils disaster_recovery status restore' command to see the status
ALERT: Please restart the server(s) before performing the next restore for changes to take effect. In case of a cluster, restart the entire cluster.
Теперь проверяем статус восстановления:
admin:utils disaster_recovery status restore
Status: SUCCESS :Restore Completed...
Tar Filename: 2019-02-16-04-21-37.tar
Storage Location: NETWORK
Operation: restore
Percentage Complete: 100
CDR_CAR CCM01 CAR SUCCESS Sun Feb 17 11:20:15 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_cdr_car_car.log
PLM CCM01 ELM-AGENT SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-agent.log
PLM CCM01 ELM-SERVER SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-server.log
UCM CCM01 BAT SUCCESS Sun Feb 17 11:25:06 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_bat.log
UCM CCM01 CCMPREFS SUCCESS Sun Feb 17 11:37:06 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_ccmprefs.log
UCM CCM01 PLATFORM SUCCESS Sun Feb 17 11:37:13 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_platform.log
UCM CCM01 TCT SUCCESS Sun Feb 17 12:11:10 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_tct.log
UCM CCM01 SYSLOGAGT SUCCESS Sun Feb 17 12:14:19 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_syslogagt.log
UCM CCM01 CDPAGT SUCCESS Sun Feb 17 12:14:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_cdpagt.log
UCM CCM01 CLM SUCCESS Sun Feb 17 12:17:03 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_clm.log
UCM CCM01 CCMDB SUCCESS Sun Feb 17 12:17:05 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ccmdb.log
UCM CCM01 TFTP SUCCESS Sun Feb 17 12:25:12 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_tftp.log
UCM CCM01 ANN SUCCESS Sun Feb 17 12:26:38 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ann.log
UCM CCM01 MOH SUCCESS Sun Feb 17 12:26:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_moh.log