Какую ФС на серверах с Linux вы используете? (Можно выбрать несколько значений)
Anonymous Poll
78%
ext4
15%
XFS
12%
BtrFS
32%
ZFS
0%
Свой вариант (в комментариях)
13%
Просто посмотреть ответы
👍3
Подключаем диск из NAS в Linux, или монтирование RAID и LVM разделов
Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.
На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...
Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.
Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.
На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.
Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.
✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/
Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.
На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...
Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.
Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.
На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.
Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.
✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/
👍9🔥3
Как изменить SID в Windows 10/11 и Server 2025
О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.
❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!
Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:
После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.
‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.
Статус можно узнать командой:
Отключить:
Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.
‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.
Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.
🔹 Затем отключите службу UCPD — это User Choice Protection Driver
Перезагрузитесь, иначе защита полноценно отключена не будет.
Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:
Введите лицензионный ключ и подтвердите свои действия, утилита завершит сеанс, и вы окажетесь на экране блокировки. Не входите в систему до завершения ее работы, особенно это важно для сервера, где могут быть удаленные сеансы.
По завершении работы компьютер автоматически перезагрузится. После чего первым делом включаем обратно службу UCPD и снова перезагружаемся.
После чего убедитесь, что SID действительно изменился.
👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:
Данная команда сбросит все современные приложения, либо, если хотите действовать точечно:
Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.
При соблюдении всех указанных подготовительных мер данный способ работает, но не нужно забывать, что он не является официальным и Microsoft такой сценарий не поддерживает. Поэтому обязательно делайте бекапы, а по возможности лучше переустановите систему.
О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.
❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!
Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:
77JAY-XcFfv-2OiLw-2f
После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.
‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.
Статус можно узнать командой:
manage-bde -status C:
Отключить:
manage-bde -off C:
Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.
‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.
Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.
🔹 Затем отключите службу UCPD — это User Choice Protection Driver
sc config UCPD start=disabled
schtasks.exe /change /Disable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
Перезагрузитесь, иначе защита полноценно отключена не будет.
Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:
SIDCHG64.exe /R
Введите лицензионный ключ и подтвердите свои действия, утилита завершит сеанс, и вы окажетесь на экране блокировки. Не входите в систему до завершения ее работы, особенно это важно для сервера, где могут быть удаленные сеансы.
По завершении работы компьютер автоматически перезагрузится. После чего первым делом включаем обратно службу UCPD и снова перезагружаемся.
schtasks.exe /change /Enable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
sc config UCPD start=auto
После чего убедитесь, что SID действительно изменился.
👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:
SIDCHG64.exe / RESETALLAPPS
Данная команда сбросит все современные приложения, либо, если хотите действовать точечно:
SIDCHG64.exe /RESETAPPS=App_1
Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.
При соблюдении всех указанных подготовительных мер данный способ работает, но не нужно забывать, что он не является официальным и Microsoft такой сценарий не поддерживает. Поэтому обязательно делайте бекапы, а по возможности лучше переустановите систему.
👍10🤔2🤮1
Режимы выделения виртуальной памяти в Linux
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
vm.overcommit_memory
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
vm.overcommit_ratio = 100
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
👍8❤1
Как в Linux узнать скорость USB-портов и их текущий режим работы
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
lsusb -t
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
👍6🔥4