오늘 방금 새 백업 드라이브를 받았기 때문에 rsync와 함께 사용했는데 모든 것이 괜찮았습니다. 백업이 실행되었고 시스템이 괜찮아 보였지만 apt-get을 사용했는데 다음 오류가 발생했습니다.
root@cloud7-media:~# apt-get install sl
W: Not using locking for read only lock file /var/lib/dpkg/lock
E: Unable to write to /var/cache/apt/
E: The package lists or status file could not be parsed or opened.
그래서 나는 괜찮다고 생각했고 아마도 버그 일 뿐이므로 재부팅했습니다. 그러면 내 시스템이 온라인 상태가 아닙니다. 내 시스템이 작동되어 실행되고 있는지 확인하기 위해 네트워크 패널로 이동했지만 그렇지 않았습니다. 모니터를 연결하고 드라이브에서 문제가 감지되었기 때문에 자동 복구 변경 사항을 수락하고 다시 부팅했습니다.
이것은 내가 사용하는 rsync 코드입니다.
rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/BTSync","/home/cloud7/torrent"} / /mnt/backup/cloud7
그런데 rsync를 다시 실행하고 시스템을 재부팅한 후 다시 오프라인 상태가 되었기 때문에 rsync가 원인임을 확인할 수 있습니다.
답변1
rsync 후에 런타임 로그를 확인해 볼 수 있습니다. 커널 로그에 Remounting filesystem read-only. 읽기만 하는 경우에도 오류가 발생하면 자동으로 발생합니다. 메모리 내 커널 로그는 를 통해 검색됩니다 dmesg. systemd를 사용하는 경우 journalctl -btmpfs를 사용하여 작업을 계속할 수도 있습니다.
다른 분들도 로그에 댓글을 다는 걸 봤어요. 명확히 말하면, 오류로 인해 파일 시스템이 읽기 전용으로 다시 마운트되면 저장된 로그 파일에 오류 메시지를 쓸 기회가 없을 수도 있습니다.파일 시스템에서:).
이에 대해 제가 이렇게 확신하는 이유는 이어지는 "드라이브에서 문제가 감지되었기 때문에 변경 사항을 자동으로 복구합니다" 때문입니다.
나는 또한 rsync가 일부 오류가 발생하더라도 적어도 계속할 수 있다는 것을 알고 있으므로 명백한 오류 메시지와 함께 반드시 조기에 중단될 필요는 없습니다. 대신 특정 파일을 전송하는 동안 오류가 발생했다는 일반적인 경고로 끝날 수 있습니다. 이는 과거에 제가 간과했던 것입니다. (또는 rsync가 오류의 영향을 전혀 받지 않을 수도 있지만, 그런 상황이 발생할 수 있는 상황은 생각나지 않습니다.)
시스템을 다시 중단할 필요가 없습니다.
하드 드라이브에 문제가 있을 수 있습니다.
SMART를 사용하여 작동을 확인하십시오. smartctl -H. 또한 smartctl -a업계를 언급하는 카운터에 특별한주의를 기울이십시오. "보류 중" 또는 "수정 불가능" 섹터가 있는 경우 드라이브에 결함이 있다고 간주하는 것이 좋습니다.
(대규모 스토리지 시스템을 구축하는 회사는 드라이브에 중복성을 사용하고, 불량 섹터를 다시 쓰고, 오류가 일시적인지 지속적인지 추측하는 알고리즘을 작성합니다. 중복 시스템(RAID)을 실행하는 것처럼 들리지 않습니다. 이러한 상황에서 드라이브를 사용하는 것은 일반적으로 하드웨어 오류로부터 복구를 시도하는 것보다 훨씬 더 중요합니다.