오늘 방금 새 백업 드라이브를 받았기 때문에 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)을 실행하는 것처럼 들리지 않습니다. 드라이브 사용으로 인한 위험은 일반적으로 하드웨어 결함을 복구하려고 시도하여 얻을 수 있는 이점보다 훨씬 더 큽니다.