📌 LG 스마트폰 백업 파일 .lbf 복구 성공기
LGBackup_230124.lbf 파일에서 사진·음악·데이터 추출하기
스마트폰을 오래 쓰다 보면 어느 순간 이런 파일을 만나게 됩니다.
LGBackup_230124.lbf
LGBackup_230124.lbf0
LGBackup_230124.lbf1
...
LGBackup_230124.lbf10
처음 보면 단순한 백업 파일처럼 보이지만, 막상 복원하려고 하면 쉽지 않습니다.
특히 LG 스마트폰이 단종된 지금은 공식 복원 환경을 맞추기도 어렵고, 삼성폰이나 PC에서 바로 열 수도 없습니다.
이번 글은 실제로 LG G8 ThinQ 백업 파일 약 49GB를 PC에서 추출한 과정을 정리한 기록입니다.
단순 사용기가 아니라, 중간에 발생한 오류를 하나씩 해결하면서 최종적으로 Done!까지 도달한 실전 복구 사례입니다.
1. 문제 상황
LG 스마트폰 백업 폴더 안에는 아래와 같은 파일들이 있었습니다.
LGBackup_230124.lbf
LGBackup_230124.lbf0
LGBackup_230124.lbf1
LGBackup_230124.lbf2
...
LGBackup_230124.lbf10
전체 용량은 약 49.8GB였습니다.
12개 파일 49,872,228,924 바이트
처음에는 메인 파일인 LGBackup_230124.lbf만 추출하면 될 줄 알았지만, 실제로는 그렇지 않았습니다.
이 백업은 단일 파일 백업이 아니라 분할 백업 세트였습니다.
2. 사용한 도구
이번 작업에 사용한 기본 도구는 다음과 같습니다.
| OS | Windows 10 |
| Python | Python 3.14 |
| Python 패키지 | pycryptodome |
| 추출 스크립트 | LG .lbf 추출용 Python 스크립트 |
| 작업 드라이브 | F:\G8 ThinQ |
| 백업 파일 크기 | 약 49.8GB |
처음에는 Python 버전과 pip 경로가 꼬여 있었습니다.
예를 들어 이런 상태였습니다.
python --version
Python 3.14.5
py -m pip --version
pip ... python 3.14
최종적으로는 python과 pip가 같은 Python 버전을 바라보도록 정리한 뒤 진행했습니다.
3. pycryptodome 설치
LG 백업 파일 내부에는 암호화/복호화 처리 과정이 필요했기 때문에 pycryptodome 패키지가 필요했습니다.
설치 명령은 다음과 같습니다.
python -m pip install pycryptodome
설치 확인은 아래처럼 했습니다.
python -c "from Crypto.Cipher import AES; print('pycryptodome OK')"
정상이라면 다음처럼 출력됩니다.
pycryptodome OK
4. 첫 번째 오류: XML 헤더 파싱 실패
처음 추출을 시도했을 때 이런 오류가 발생했습니다.
xml.etree.ElementTree.ParseError: reference to invalid character number
이 오류는 백업 파일 헤더 안의 XML 데이터에 Python XML 파서가 허용하지 않는 문자 참조가 들어 있어서 발생한 문제였습니다.
즉, 백업 파일 자체가 완전히 깨진 것은 아니고, 스크립트가 LG 백업 헤더 안의 예외적인 문자를 처리하지 못한 상황이었습니다.
그래서 XML 파싱 전에 잘못된 제어문자와 비정상 문자 참조를 제거하도록 스크립트를 수정했습니다.
핵심 방향은 다음과 같습니다.
xml_text = res2.decode("utf-8", errors="ignore")
# XML 1.0에서 허용되지 않는 실제 제어문자 제거
xml_text = re.sub(r'[\x00-\x08\x0B\x0C\x0E-\x1F]', '', xml_text)
# XML 1.0에서 허용되지 않는 숫자 문자 참조 제거
xml_text = re.sub(r'&#(x[0-9a-fA-F]+|[0-9]+);', _clean_xml_charref, xml_text)
return ET.fromstring(xml_text)
이 수정 후 XML 헤더 파싱 오류는 넘어갈 수 있었습니다.
5. 두 번째 오류: 잘못된 new header 인식
XML 파싱을 넘기자 이번에는 아래 오류가 발생했습니다.
Header start offset: 7021235168358591849
Exception: Invalid header length.
여기서 중요한 점은 숫자입니다.
백업 메인 파일 크기는 약 3.8GB인데, 헤더 시작 위치가 말도 안 되게 큰 값으로 잡혔습니다.
즉, 스크립트가 이 백업 파일을 new header 방식으로 잘못 해석하고 있었습니다.
그래서 new header 재시도를 막고, 정상적으로 읽힌 old header 방식만 사용하도록 수정했습니다.
FORCE_NEW_HEADER = False
그리고 readHeader(True) 호출을 readHeader(False)로 바꿨습니다.
이후 헤더는 정상적으로 읽혔습니다.
[+] Header read OK
6. 세 번째 오류: 분할 파일 미지원
이후 실제 데이터 추출 단계로 넘어갔지만, 다음 오류가 발생했습니다.
Error extracting '701_CG_154': Data too large; end: 3911229636
이 오류의 의미는 명확했습니다.
메인 파일 LGBackup_230124.lbf의 크기는 약 3,899,916,941 바이트인데, 추출하려는 데이터 끝 위치가 그보다 큰 위치를 가리키고 있었습니다.
즉, 데이터가 메인 .lbf 파일 하나 안에만 있는 게 아니라 다음 조각 파일로 이어지고 있었습니다.
백업 구조는 이런 형태였습니다.
LGBackup_230124.lbf
LGBackup_230124.lbf0
LGBackup_230124.lbf1
LGBackup_230124.lbf2
...
LGBackup_230124.lbf10
기존 스크립트는 메인 .lbf 파일 하나만 열고 있었기 때문에, .lbf0 ~ .lbf10 조각 파일을 읽지 못했습니다.
그래서 분할 파일 전체를 하나의 가상 파일처럼 읽도록 패치했습니다.
결과적으로 다음 로그가 출력되었습니다.
[+] Backup virtual size: 49872228924
[+] Backup parts: LGBackup_230124.lbf, LGBackup_230124.lbf0, LGBackup_230124.lbf1, ...
이 단계가 가장 중요했습니다.
7. 네 번째 오류: checkNullData 함수 오류
분할 파일 인식까지 성공했지만, 다시 이런 오류가 발생했습니다.
name 'checkNullData' is not defined
원래 스크립트 안에 NULL 데이터 여부를 검사하는 로직이 있었는데, 패치 과정에서 해당 함수가 없는 상태로 호출되고 있었습니다.
복구 목적에서는 NULL 데이터 스킵보다 실제 파일 추출 성공이 더 중요했기 때문에, 해당 검사를 제거했습니다.
핵심 수정 방향은 다음과 같습니다.
usedList.append((offset, length))
name = os.path.join("export", name)
이후 checkNullData 오류는 해결됐습니다.
8. 다섯 번째 오류: 하위 폴더 자동 생성 문제
이제 파일명까지 정상적으로 읽혔지만, 다음 오류가 발생했습니다.
No such file or directory: 'export\\misc/internal/Preload/LG/파일명.flac'
이건 파일 추출 자체의 문제가 아니라, 저장하려는 하위 폴더가 아직 생성되지 않은 상태에서 파일을 쓰려고 해서 생긴 오류였습니다.
예를 들어 아래 경로에 파일을 쓰려면:
export\misc\internal\Music\sample.mp3
먼저 이 폴더들이 생성되어 있어야 합니다.
그래서 파일 저장 전에 부모 폴더를 자동 생성하도록 수정했습니다.
parent_dir = os.path.dirname(name)
if parent_dir:
os.makedirs(parent_dir, exist_ok=True)
이후 실제 파일 추출이 정상적으로 시작되었습니다.
9. 실제 추출 진행
추출이 시작되면 이런 식으로 진행률이 표시됐습니다.
Extracting data...
[+] File is not locked
21/16718
여기서 16718은 백업 안에 기록된 전체 항목 수입니다.
중간 진행 기록은 다음과 같았습니다.
| 22:55 | 4440 / 16718 | 약 26.6% |
| 23:00 | 6666 / 16718 | 약 39.9% |
| 23:06 | 9330 / 16718 | 약 55.8% |
| 23:11 | 14380 / 16718 | 약 86.0% |
| 완료 | 16718 / 16718 | 100% |
중간에 속도가 느려지는 구간도 있었고, 마지막 2개 파일에서 잠시 지연되기도 했습니다.
하지만 최종적으로 아래 메시지가 출력됐습니다.
16718/16718
Looking for missed data...
Overlap!: pos: 3911229636 start: 3896352256
Overlap!: pos: 3899916928 start: 3896352256
Done!
Overlap! 메시지는 치명적 오류가 아니었습니다.
이미 추출된 영역과 헤더 영역이 겹친다는 의미에 가까웠고, 마지막에 Done!이 출력되었기 때문에 추출은 정상 종료된 것으로 판단했습니다.
10. 추출 결과 확인
추출된 파일은 아래 폴더에 저장되었습니다.
F:\G8 ThinQ\export\
특히 LG폰 내부 저장소 데이터는 주로 아래 경로에 있었습니다.
F:\G8 ThinQ\export\misc\internal\
추출된 파일을 확인하기 위해 다음 명령을 사용했습니다.
전체 파일 목록 저장
dir /s /b export > extracted_all_files.txt
사진/영상 목록 저장
dir /s /b export\*.jpg export\*.jpeg export\*.png export\*.heic export\*.mp4 export\*.3gp export\*.mov > photo_video_list.txt
DB/연락처/문자 후보 목록 저장
dir /s /b export\*.db export\*.sqlite export\*.vcf export\*.vmsg export\*.csv > db_contact_sms_list.txt
파일 개수 확인
find /c /v "" extracted_all_files.txt
find /c /v "" photo_video_list.txt
find /c /v "" db_contact_sms_list.txt
11. 이번 작업의 핵심 정리
이번 복구 과정은 단순히 “툴 하나 실행해서 끝”나는 작업이 아니었습니다.
실제로는 아래 문제들을 하나씩 해결해야 했습니다.
| 1 | Python / pip 경로 꼬임 | Python 실행 환경 정리 |
| 2 | pycryptodome 필요 | 패키지 설치 |
| 3 | XML 헤더 파싱 오류 | 비정상 문자 제거 패치 |
| 4 | new header 오판 | old header 강제 |
| 5 | 분할 백업 미지원 | .lbf0~.lbf10 가상 연결 |
| 6 | checkNullData 함수 오류 | NULL 검사 제거 |
| 7 | 하위 폴더 미생성 | os.makedirs() 추가 |
| 8 | 실제 추출 | 16,718개 항목 추출 완료 |
12. 주의할 점
이 방식은 공식 LG 복원 방식이 아닙니다.
따라서 다음 사항은 꼭 주의해야 합니다.
원본 파일은 절대 직접 수정하지 말 것
항상 복사본으로 작업해야 합니다.
LGBackup_230124.lbf
LGBackup_230124.lbf0
...
LGBackup_230124.lbf10
이 파일들은 원본 그대로 보존하는 것이 좋습니다.
충분한 저장 공간 필요
이번 백업은 약 49.8GB였습니다.
추출 결과까지 감안하면 최소 100GB 이상 여유 공간이 필요합니다.
사진·영상이 많다면 150GB 이상을 권장합니다.
모든 분할 파일이 같은 폴더에 있어야 함
분할 백업은 하나라도 빠지면 정상 추출이 어렵습니다.
LGBackup_230124.lbf
LGBackup_230124.lbf0
LGBackup_230124.lbf1
...
LGBackup_230124.lbf10
반드시 같은 폴더에 모아둔 상태에서 작업해야 합니다.
파일 순서 주의
Windows 정렬에서는 .lbf10이 .lbf2보다 먼저 보일 수 있습니다.
.lbf1
.lbf10
.lbf2
이건 문자열 정렬 때문입니다.
실제 논리 순서는 숫자 기준입니다.
.lbf0
.lbf1
.lbf2
...
.lbf10
13. 이 작업에서 얻은 교훈
이번 작업에서 느낀 가장 큰 포인트는 이것입니다.
전문가가 아니어도, 로그를 정확히 보고 하나씩 해결하면 복구 가능성이 열린다.
처음에는 단순히 .lbf 파일 하나를 열면 될 줄 알았습니다.
하지만 실제로는 XML 파싱, 헤더 방식, 분할 파일, 경로 생성 등 여러 문제가 엮여 있었습니다.
그럼에도 불구하고 로그를 기준으로 하나씩 원인을 좁혀가니 최종적으로 추출에 성공했습니다.
IT 작업에서 중요한 건 “한 번에 아는 것”보다 문제를 잘게 나누고, 로그를 보고, 원인을 분리하는 것입니다.
최종 결론
LG 스마트폰 백업 파일 .lbf는 단순 압축파일처럼 쉽게 열리는 구조는 아닙니다.
특히 아래처럼 분할 파일이 있는 경우:
LGBackup_230124.lbf
LGBackup_230124.lbf0
LGBackup_230124.lbf1
...
기존 추출 스크립트만으로는 실패할 수 있습니다.
하지만 Python 환경을 정리하고, XML 파싱 문제와 분할 파일 읽기 문제를 해결하면 PC에서도 사진, 음악, 영상, DB 파일 등을 추출할 수 있습니다.
이번 사례에서는 최종적으로:
16718 / 16718
Done!
까지 도달했고, export 폴더 아래에 실제 파일들이 정상적으로 생성되었습니다.
한 줄 정리
LG .lbf 백업 파일 복구는 공식 복원이 막혀도 끝이 아니다. 로그를 기준으로 헤더·분할파일·경로 문제를 해결하면 PC에서 직접 추출할 수 있다.