BACKUP1 ファイルとは？開き方・変換方法まとめ

BACKUP1 ファイル形式とは？

.backup1ファイルは、Androidデバイスの標準システムリカバリモード（主に古いSamsungのスマートフォンやタブレットで見られる）によって作成される分割バックアップの2番目のパーツです。デバイスがuserdataパーティションをバックアップする際、コピーを保存するSDカードは通常FAT32形式であり、約2GBを超えるファイルを保存できません。リカバリはこの制限を回避するために、イメージを2GBずつのスライスに書き込みます。最初のファイルは.backup、次は.backup1、その次は.backup2という名前になります。各ファイルには、userdata_20240101_000617.backup1のようにタイムスタンプが含まれます。

.backup1パーツ単体では不完全です。すべてのパーツを合わせることで、連絡先、アプリデータ、メディア、設定を含むuserdataパーティションの1つのイメージが形成されます。各2GBのスライスは、ペイロードではない512バイトのヘッダーブロックで始まります。ヘッダーを取り除き、パーツを順番に結合すると、結果は通常raw ext4ファイルシステムになりますが、一部のデバイスでは代わりにgzip圧縮されたtarストリームが保存されます。名前は似ていますが、これはadb backupによって生成される.ab形式とは異なります。

セキュリティと安全性

リスク： LOW

A .backup1 part is inert data, not executable, so it cannot run on its own. The main practical risk is data loss during reassembly: extract with read-only mounts and work on copies, since a missing or out-of-order part yields a corrupt ext4 image. The backup is unencrypted, so treat it as sensitive personal data because it can contain contacts, messages, and app credentials.

形式の詳細

概要

正式名称Split Android Recovery Backup File (part 2)別名 Split Android Backup File, Android Recovery Backup part 1

開発元Google / Android device vendors (Samsung stock recovery)登場時期 Early 2010s (Android device recovery backups)

カテゴリバックアップファイル

MIME タイプapplication/octet-stream

タイプBinary container; segment of an ext4 partition image (or gzip+tar stream)

BACKUP1 ファイルを開くプログラム

Windows2 apps

7-Zip オープンソース For the gzip-tar variant, once the 512-byte header is removed, 7-Zip can open the resulting gzip and tar layers to extract the archived files.

DiskInternals Linux Reader フリーミアム After you concatenate the header-stripped parts into a single ext4 image, open that image in Linux Reader to browse and export files from the ext4 filesystem on Windows.

Linux3 apps

dd + mount (coreutils / util-linux) オープンソース Strip the 512-byte header from each part with dd (skip=512), append the parts in order into one img.ext4, then mount it read-only as ext4 with mount -t ext4 -o loop,ro to browse the userdata contents.

gunzip + tar (GNU tar) オープンソース For the gzip-tar variant, pipe the header-stripped stream through gunzip and tar (dd if=userdata_....backup skip=1 bs=512 | gunzip -c | tar xv) to unpack files directly without mounting.

e2fsprogs (debugfs / dumpe2fs) オープンソース After reassembling the ext4 image, use debugfs to inspect and extract individual files or run fsck.ext4 to repair a damaged image before mounting.

技術的詳細

詳細仕様

Encoding	Binary. Raw ext4 filesystem bytes, or a gzip-compressed tar stream, depending on the device recovery implementation.
Byte order	Little-endian (ext4 on ARM Android devices)
Container	Split segment: one slice of a larger logical image spread across .backup, .backup1, .backup2 and so on.
Compression	None for the raw-ext4 variant; gzip (DEFLATE) for the tar-based variant seen on some devices.
Encryption	None by default. The stock recovery backup is unencrypted, which is what makes offline extraction with dd/mount possible.
Typical size	About 2 GB per part; the recovery splits at the ~2GB boundary imposed by FAT32 SD cards.
Structure	Each part begins with a 512-byte header block that must be stripped, then holds a 2GB slice of the payload. Parts are numbered .backup (first), .backup1 (second), .backup2 (third) and continue sequentially. Concatenating the header-stripped payloads reconstructs a single ext4 image (or a single gzip+tar stream).
Integrity	No standard embedded checksum documented; integrity depends on all parts being present and concatenated in order.
Platforms	Android
Notes	Files carry a timestamped name such as userdata_yyyymmdd_HHMMSS.backup1 and are written to the device SD card by System Recovery Mode. This is distinct from the adb backup .ab (Android Backup) format. Reassembly command pattern: dd if=userdata_....backup1 skip=512 bs=128k iflag=skip_bytes oflag=append conv=notrunc of=img.ext4 (repeated per part), then mount -t ext4 -o loop img.ext4 /mnt.
Structure Type	Split multi-part image
リリース日	Early 2010s (Android device recovery backups)