LinuxDev Portal
Назад към каталога
Илюстрация на автоматизация: терминал, зъбчати колела и конвейер от задачи
Автоматизация v1.0.0 • 5.10.2026 г. • 🐚 bash

Proxmox SSD Read-only fix - Поправка след токов удар

Bash скрипт за автоматична поправка на EXT4 SSD дискове в Proxmox, които влизат в Read-only режим след токов удар. Включва fsck, unmount, write test и SMART проверка.

Зависимости

bashutil-linuxe2fsprogssmartmontools

Употреба

chmod +x ssd-repair.sh sudo ./ssd-repair.sh
bashproxmoxssdfsckext4read-onlyrepairautomationsmartctl

Ако търсите работещ Proxmox SSD Read-only fix, вероятно вече сте се сблъсквали с внезапно спиране на тока, което оставя вашата система в режим „само за четене“. Днес ми се случи точно това – след рестарт на сървъра, SSD дискът с бекъпите се оказа заключен.

Когато Linux открие логически грешки във файловата система (често явление при токови удари и SSD дискове), той автоматично заключва дяла, за да предпази данните от по-нататъшно повреждане. Това обаче спира всички автоматични бекъп процеси и създава главоболия.

Вместо всеки път да изпълнявам ръчно серия от команди за размонтиране, поправка и проверка, реших да създам един надежден Bash скрипт.

Какво прави този скрипт?

Скриптът е проектиран да бъде „умна“ застраховка за вашия SSD. Ето основните му функции:

  • Безопасност на първо място: Пита за потвърждение преди всяко критично действие.
  • Интелигентен Unmount: Спира процесите, които блокират диска, и използва „lazy“ unmount (umount -l), за да гарантира, че ремонтът може да започне.
  • Автоматична поправка: Изпълнява fsck -fvy с нужните флагове за автоматично коригиране на грешките.
  • Верификация: След поправката прави тест за запис, за да е сигурен, че дискът отново е в режим „Read-Write“.
  • Здравен статус: Извлича SMART информацията на физическото устройство, за да провери дали дискът не заминава хардуерно.
  • Логване: Всички действия и резултати се записват в хронологичен лог файл (repair.log) за бъдещи справки.

Вече не се притеснявам от следващия токов удар – знам, че поправката е само на един скрипт разстояние. Надявам се това решение да бъде полезно и на други, които искат да поддържат своите бекъп дискове в топ форма!

Можете да копирате целия скрипт отдолу.

Защо се стига до Read-Only режим при Proxmox?

Много потребители на Proxmox използват стандартни потребителски SSD дискове за своите бекъпи. Макар и бързи, те често нямат вградена защита срещу загуба на захранване (Power Loss Protection – PLP). Когато настъпи внезапен рестарт:

  1. Journaling Failure: Файловата система EXT4 използва „журнал“, за да следи промените. При прекъсване на тока журналът се поврежда.
  2. Защита на ядрото: Linux ядрото открива несъответствие в метаданните и автоматично превключва диска в режим „само за четене“, за да предотврати по-големи щети (data corruption).

Разбор на командите в скрипта: Какво се случва „под капака“?

За да разберете как работи нашият Proxmox SSD Read-only fix, нека разгледаме основните команди:

  • umount -l (Lazy Unmount): Критична стъпка. Тъй като Proxmox често „държи“ диска чрез различни услуги, стандартният umount може да се провали. Флагът -l позволява на диска да бъде разкачен веднага щом ресурсите се освободят.
  • fsck -fvy:
    • -f – форсира проверката, дори ако системата изглежда чиста.
    • -v (verbose) – дава подробна информация.
    • -y (yes) – автоматично отговаря с „да“ на всички предложения за поправка – жизненоважно за автоматизацията.
  • smartctl -H: Комуникира директно с фърмуера на SSD-то. Казва ни дали дискът има хардуерен дефект или просто логическа грешка.
  • Write Test: Създава временен файл и го изтрива – най-бързият начин да проверим дали файловата система отново е writable.

Как да използвате скрипта?

  1. Запазете скрипта като ssd-repair.sh
  2. Дайте права за изпълнение: 
    chmod +x ssd-repair.sh
  3. Стартирайте като root: 
    sudo ./ssd-repair.sh

Важно: Преди първото стартиране редактирайте двете променливи в началото на скрипта според вашата система:

MOUNT_POINT="/mnt/backup"   # къде е монтиран дискът
DEVICE="/dev/sda1"          # точният дял

Как да предотвратим този проблем в бъдеще?

Въпреки че скриптът ще ви спаси в 99% от случаите, превенцията е най-добрият инструмент:

  1. Инвестиция в UPS – Дори малко устройство ще даде на Proxmox време да изпрати сигнал за poweroff.
  2. Настройка на /etc/fstab – Можете да добавите параметри като errors=remount-ro, но това е стандартното поведение. По-важно е да следите здравето на диска (Wearout Level) в интерфейса на Proxmox.
  3. Enterprise SSD – Ако бюджетът позволява, използвайте дискове с кондензатори за защита на кеша (PLP), които са създадени точно за такива ситуации.

Често задавани въпроси (FAQ)

Ще загубя ли данни при ползване на скрипта?
fsck се опитва да спаси максимално много данни. В редки случаи повредени малки файлове могат да бъдат преместени в папка lost+found.

Мога ли да ползвам скрипта за други файлови системи (напр. ZFS)?
Не, този конкретен скрипт е за EXT4. ZFS има свои механизми за поправка (zpool scrub / zpool import).

Какво означават кодовете на fsck?

  • 0 → без грешки
  • 1 → грешки са поправени
  • 2 → системно трябва да се рестартира
  • ≥4 → сериозен проблем (скриптът спира)

Целият скрипт

#!/bin/bash
# =============================================================
# SSD Repair Script (ext4/auto) - Proxmox Edition (Final)
# =============================================================
# 🔙 Обратно към статията:
# https://itpraktika.com/proxmox-ssd-read-only-fix/

MOUNT_POINT="/mnt/backup"
DEVICE="/dev/sda1"
LOG_FILE="repair.log"

# Цветове
RED="\e[31m"
GREEN="\e[32m"
YELLOW="\e[33m"
CYAN="\e[36m"
RESET="\e[0m"

# Проверка за root
if [ "$EUID" -ne 0 ]; then
    echo -e "${RED}❌ Стартирай скрипта като root (sudo)!${RESET}"
    exit 1
fi

# Подобрена лог функция (с разделител за по-добра четимост)
log_message() {
    echo -e "$1"
    # Записваме в лога без цветови кодове (за чист текст)
    local clean_msg=$(echo -e "$2" | sed 's/\x1b\[[0-9;]*m//g')
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $clean_msg" >> "$LOG_FILE"
}

clear
echo -e "${CYAN}==========================================${RESET}"
echo -e "${CYAN}    SSD REPAIR TOOL - СИСТЕМА ЗА БЕКЪПИ    ${RESET}"
echo -e "${CYAN}==========================================${RESET}"
echo -e "Лог файл: ${YELLOW}$LOG_FILE${RESET}"
echo ""

# Потвърждение
echo -e "${YELLOW}ВНИМАНИЕ: Скриптът ще извърши fsck върху $DEVICE.${RESET}"
read -p "Сигурен ли си? (y/n): " confirm
if [[ $confirm != [yY] ]]; then
    echo -e "${RED}❌ Операцията е отменена.${RESET}"
    exit 0
fi

# Добавяме празен ред в лога за разделител между отделните пускания
echo "----------------------------------------------------------" >> "$LOG_FILE"
log_message "${CYAN}===> Старт на операция за $DEVICE${RESET}" "STARTING NEW SESSION"

# 1. Проверка mount point
if [ ! -d "$MOUNT_POINT" ]; then
    log_message "${RED}❌ Липсва mount point: $MOUNT_POINT${RESET}" "ERROR: Missing mount point directory"
    exit 1
fi

# 2. Проверка дали е монтиран и unmount
if mountpoint -q "$MOUNT_POINT"; then
    log_message "${YELLOW}⚠️ Дискът е монтиран.${RESET}" "Status: Mounted"

    # Показваме кои процеси пречат
    BUSY_PIDS=$(fuser -m "$MOUNT_POINT" 2>/dev/null)
    if [ -n "$BUSY_PIDS" ]; then
        echo -e "${CYAN}Процеси използващи диска (PIDs):${RESET} $BUSY_PIDS"
        read -p "Да бъдат ли спрени процесите автоматично? (y/n): " kill_confirm
        if [[ $kill_confirm == [yY] ]]; then
            log_message "${YELLOW}⚠️ Спиране на процеси...${RESET}" "Action: Killing processes $BUSY_PIDS"
            fuser -km "$MOUNT_POINT" 2>/dev/null
            sleep 2
        fi
    fi

    echo -e "${CYAN}Опит за unmount...${RESET}"
    umount -l "$MOUNT_POINT"   # -l за по-сигурен unmount
    if mountpoint -q "$MOUNT_POINT"; then
        log_message "${RED}❌ Unmount неуспешен!${RESET}" "ERROR: Umount failed"
        exit 1
    else
        log_message "${GREEN}✅ Успешен unmount${RESET}" "Status: Unmount OK"
    fi
else
    log_message "${GREEN}✅ Вече е unmounted${RESET}" "Status: Already unmounted"
fi

# 3. fsck (Най-важната част)
log_message "${CYAN}===> Стартиране на fsck...${RESET}" "Action: Running fsck"
fsck -fvy "$DEVICE"
FSCK_RET=$?

if [ $FSCK_RET -lt 4 ]; then
    log_message "${GREEN}✅ fsck OK (код: $FSCK_RET)${RESET}" "Result: fsck Success"
else
    log_message "${RED}❌ fsck проблем (код: $FSCK_RET)${RESET}" "Result: fsck Critical Failure"
    exit 1
fi

# 4. mount обратно
log_message "${CYAN}===> Монтиране...${RESET}" "Action: Remounting"
mount "$DEVICE" "$MOUNT_POINT"
if [ $? -ne 0 ]; then
    log_message "${RED}❌ mount грешка${RESET}" "Result: Mount Failed"
    exit 1
else
    log_message "${GREEN}✅ mount OK${RESET}" "Result: Mount Success"
fi

# 5. Тест за запис
TEST_FILE="$MOUNT_POINT/repair_test_$(date +%s).tmp"
if touch "$TEST_FILE" 2>/dev/null; then
    rm "$TEST_FILE"
    log_message "${GREEN}✅ WRITE TEST OK${RESET}" "Write Test: PASSED"
else
    log_message "${RED}❌ WRITE TEST FAIL (Read-Only?)${RESET}" "Write Test: FAILED"
fi

# 6. SMART и Kernel logs (само на екрана)
echo -e "\n${CYAN}===> Последни kernel съобщения:${RESET}"
dmesg | tail -n 15

PARENT_DISK=$(lsblk -no PKNAME "$DEVICE")
if [ -n "$PARENT_DISK" ] && command -v smartctl >/dev/null 2>&1; then
    echo -e "\n${CYAN}===> SMART статус (/dev/$PARENT_DISK):${RESET}"
    smartctl -H "/dev/$PARENT_DISK" | grep -iE "result|status|health"
fi

log_message "${GREEN}===> ВСИЧКО ЗАВЪРШИ УСПЕШНО${RESET}" "SESSION FINISHED SUCCESSFULLY"
Всички скриптове