방금 49GB 디렉토리를 잘못된 파일 경로에 "mv"했습니다. 파일의 원래 상태를 복원할 수 있습니까?

방금 49GB 디렉토리를 잘못된 파일 경로에 "mv"했습니다. 파일의 원래 상태를 복원할 수 있습니까?

나는 (글쎄, 나는가졌다) 디렉토리:

/media/admin/my_data

크기는 약 49GB였으며 그 안에 수만 개의 파일이 들어있었습니다. 디렉터리는 활성 LUKS 파티션의 마운트 지점입니다.

디렉토리 이름을 다음과 같이 바꾸고 싶었습니다.

/media/admin/my_data_on_60GB_partition

당시에는 몰랐지만 홈 디렉터리에서 명령을 실행하여 다음을 수행하게 되었습니다.

~% sudo mv /media/admin/my_data my_data_on_60GB_partition

그래서 프로그램은 새로운 디렉토리로 mv옮겨지기 시작했습니다 ./media/admin/my_data~/my_data_on_60GB_partition

Ctrl+를 사용하여 C명령을 도중에 취소했으므로 이제 디렉터리 전체에 걸쳐 많은 파일이 분할됩니다.

~/my_data_on_60GB_partition    <---  about 2GB worth files in here

그리고

/media/admin/my_data           <---- about 47GB of orig files in here    

새 디렉토리 ~/my_data_on_60GB_partition와 일부 하위 디렉토리는 루트가 소유합니다. 나는 프로그램이 처음에 루트로 파일을 복사한 다음 전송 후에 해당 파일을 내 사용자 계정으로 다시 복사했음
에 틀림없다고 가정합니다 .mvchown

디렉터리/파티션에 대한 다소 오래된 백업이 있습니다.
내 질문은,이동된 파일 묶음을 안정적으로 복원할 수 있습니까?

즉, 그냥 실행할 수 있습니까?

sudo mv ~/my_data_on_60GB_partition/*  /media/admin/my_data

아니면 파일이 손상되었거나 부분적으로 완료되었을 가능성이 있으므로 복구 시도를 포기해야 합니까?

  • 운영체제 - 우분투 16.04
mv --version  
mv (GNU coreutils) 8.25

답변1

파일 시스템 간에 파일을 이동할 때,mv 복사가 완료되기 전에 파일을 삭제하지 않고 파일을 순차적으로 처리합니다. (처음에는 각 파일을 복사한 다음 차례로 삭제한다고 말했지만 보장되지는 않습니다. 최소한 GNU는 mv각 파일을 복사한 다음 삭제합니다.명령줄 인수차례로, 그리고POSIX는 이 동작을 지정합니다). 따라서 대상 디렉터리에는 최대 하나의 불완전한 파일이 있어야 하며 원본은 여전히 ​​소스 디렉터리에 있습니다.

항목을 다시 이동하려면 아무 것도 덮어쓰지 않도록 -i플래그 를 추가하세요.mv

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

(에서 복원할 숨겨진 파일이 없다고 가정 ~/my_data_on_60GB_partition/) 또는 더 나은 방법은(발견한 대로 삭제 대기 중인 파일이 많이 있을 수 있다는 점을 고려) 플래그를 추가하여 -n아무것도 mv덮어쓰지 않지만 그것에 대해 물어보세요:

sudo mv -n ~/my_data_on_60GB_partition/* /media/admin/my_data/

플래그를 추가하여 -v수행 중인 작업을 확인할 수도 있습니다.

POSIX 호환 의 경우 mv원래 디렉토리 구조는 그대로 유지되어야 하므로 이를 확인하고 간단히 삭제할 수 있습니다 /media/admin/my_data. (일반적인 경우 변형이 mv -n안전한 접근 방식이라고 생각합니다. mv, 포함예를 들어 mv /media/admin/my_data/* my_data_on_60GB_partition/.)

일부 권한을 복원해야 할 수도 있습니다. 넌 그렇게 할 수 있어한꺼번에chown및를 사용 chmod하거나 및를 사용하여 백업에서 복원합니다 getfacl( setfacl덕분에사토 카츠라에 대한알림).

답변2

Stephen Kitt의 답변을 얻고 이 명령을 잠재적인 해결책으로 논의한 후:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

나는 무슨 일이 일어나고 있는지 이해할 때까지 실행을 보류하기로 결정했습니다. 이 답변은 내가 발견하고 결국 수행한 작업을 설명합니다.

mv파일을 대상에 복사하는 Gnu를 사용하고 있으며 복사 작업이 성공한 경우에만 원본을 삭제합니다.
그러나 나는 이 시퀀스를 한 번에 한 파일씩 수행하는지 확인하고 싶었습니다. mv그것이 사실이라면 원본 폴더 내용은 두 부분으로 깔끔하게 분할되어 한 부분은 대상으로 이동되고 다른 부분은 여전히 ​​소스에 남아 있을 것입니다. 그리고 두 디렉터리 사이에 공통적으로 복사하는 동안 중단된 파일이 하나 있을 수 있으며 형식이 잘못되었을 수 있습니다.

두 디렉토리 사이에 공통된 파일을 찾기 위해 다음을 실행했습니다.

~% sudo diff -r --report-identical-files my_data_on_60GB_partition/. /media/admin/mydata/. | grep identical | wc -l
14237

이 결과는 소스 디렉터리와 대상 디렉터리 모두에 동일한 파일의 인스턴스가 14,237개 있다는 것을 암시했으며, 파일을 수동으로 확인하여 확인했습니다. 예, 두 디렉터리 모두에 동일한 파일이 많이 있었습니다. 이는 mv많은 양의 파일을 복사한 후에만 소스 파일 삭제를 수행함을 의미합니다. 명령 info에 대한 빠른 조회가 표시되었습니다.mv

[ mv] 먼저 요청된 디렉터리와 파일을 복사하는 데 사용된 것과 동일한 코드 중 일부를 사용한 cp -a다음 (복사가 성공했다고 가정하고) 원본을 제거합니다. 복사가 실패하면 대상 파티션에 복사된 부분이 제거됩니다.

명령을 실행하지 않았지만 실행을 시도한 것 같습니다.

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

그만큼-i 덮어쓰기 전에 프롬프트아마도 14,000번 이상 트리거되었을 것입니다.

그런 다음 새로 생성된 디렉터리에 총 파일 수를 확인하려면 다음을 수행하세요.

~% sudo find my_data_on_60GB_partition/ -type f -a -print | wc -l                                                                    
14238

따라서 새 디렉터리에 총 14238개의 일반 파일이 있고 14237개가 소스에 동일한 원본이 있는 경우 이는 소스에 해당하는 동일한 파일이 없는 파일이 새 디렉터리에 하나만 있다는 의미입니다. 해당 파일이 무엇인지 확인하기 위해 소스 방향으로 rsync를 다시 실행했습니다.

~% sudo rsync -av --dry-run my_data_on_60GB_partition/ /media/admin/my_data
sending incremental file list
./
Education_learning_reference/
Education_learning_reference/Business_Education/
Education_learning_reference/Business_Education/Business_education_media_files/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/018 business plans-identifying main KPIs.flv

sent 494,548 bytes  received 1,881 bytes  330,952.67 bytes/sec
total size is 1,900,548,824  speedup is 3,828.44 (DRY RUN)

빠른 검사 결과 파일이 원본과 대상 모두에 존재하는 잘못된 형식의 파일(대상 파일=64MB, 원본=100MB)이라는 것이 확인되었습니다. 이 파일과 해당 디렉터리 계층 구조는 여전히 루트의 소유였으며 아직 원래 권한이 복원되지 않았습니다.

요약하면 다음과 같습니다.

  • 도달하지 못한 모든 파일은 mv여전히 ​​원래 위치로 돌아갑니다(분명히).
  • 완전히 복사된 모든 파일은 mv여전히 ​​소스 디렉토리에 원본 복사본을 가지고 있습니다.
  • 부분적으로만 복사된 파일은 여전히 ​​원본 디렉터리에 원본이 남아 있습니다.

즉, 모든 원본 파일은 그대로 유지되었으며 이 경우 해결책은 단순히 새 디렉터리를 삭제하는 것이었습니다!

답변3

나는 어떤 사람들이 일을 병렬로 실행하기 위해 'xargs'를 믹스에 던지려는 유혹을 받을 수 있다고 언급하고 싶다고 생각했습니다. 그것은 나에게 의지를 주고 위의 rsync 솔루션을 정말 좋아합니다.

이동 및 복사에 관한 파일 시스템 항목과 원본이 정확히 삭제되는 경우 VFS와 기본 파일 시스템은 삭제 단계에 도달하기 전에 파일별 원자성을 보장하기 위해 조정됩니다. 따라서 대상 파일이 완전히 기록되기 전에 중단되더라도 VFS의 모든 잠금은 매우 엄격하며 병렬 경우에도 무작위 데이터 인터리빙과 같은 것을 방지합니다. (저는 Linux VFS 및 NFS4 관련 작업을 했습니다)

혼합에 'xargs'를 추가하면 전송 중에 여러 파일이 있는 이중 온전성 확인 단계가 골치 아픈 일이 되었을 것입니다. 시스템 수준 스크립팅이 더 많았으면 좋았을 텐데요. 나에게 좋은 알림입니다!

거미줄에 좋은 질문이 마음에 들었고 다시 rsync를 좋아하게 되었습니다. 건배!

관련 정보