Qu'est-ce que le format de fichier BACKUP1 ?
Un fichier .backup1 est la deuxième partie d'une sauvegarde fractionnée effectuée par le mode de récupération système d'origine d'un appareil Android, que l'on trouve le plus souvent sur les anciens téléphones et tablettes Samsung. Lorsque l'appareil sauvegarde sa partition userdata, la carte SD contenant la copie est généralement formatée en FAT32, qui ne peut pas stocker de fichier de plus de 2 Go environ. La récupération contourne cette limite en écrivant l'image par tranches de 2 Go : la première est nommée .backup, la suivante .backup1, puis .backup2, et ainsi de suite. Chaque fichier porte un horodatage, par exemple userdata_20240101_000617.backup1.
À elle seule, une partie .backup1 est incomplète. Ensemble, les parties forment une image unique de la partition userdata, contenant les contacts, les données d'application, les médias et les paramètres. Chaque tranche de 2 Go commence par un bloc d'en-tête de 512 octets qui ne fait pas partie des données utiles. Une fois les en-têtes supprimés et les parties jointes dans l'ordre, le résultat est généralement un système de fichiers ext4 brut, bien que certains appareils stockent à la place un flux tar compressé avec gzip. Malgré le nom similaire, il ne s'agit pas du format .ab produit par adb backup.
Sécurité et sûreté
RISQUE : LOWA .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.
Détails du format
en bref- Generic incremental backup part - Some backup utilities append .backup1, .backup2 as generation or rotation numbers to any file's backup copy, unrelated to Android.
- Editor/app numbered backup copy - A few programs write .backup1 as a second-newest safety copy alongside .backup when saving a document or config.
Programmes qui ouvrent les fichiers BACKUP1
Windows2 apps
7-Zip
Open-source 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
Freemium 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)
Open-source 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)
Open-source 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)
Open-source After reassembling the ext4 image, use debugfs to inspect and extract individual files or run fsck.ext4 to repair a damaged image before mounting. Détails techniques
spécifications approfondies| 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 |
| Publié | Early 2010s (Android device recovery backups) |
Conversions BACKUP1
Q&R de la communauté
posées par les utilisateursPas encore de questions - soyez le premier à poser une question sur les fichiers BACKUP1.
Foire aux questions
Puis-je ouvrir un fichier .backup1 seul ?
.backup1 n'est que la deuxième tranche d'une image plus large. Vous avez besoin de la première partie .backup correspondante et de toutes les parties suivantes .backup2, .backup3, provenant toutes de la même sauvegarde, avant de pouvoir réassembler et lire quoi que ce soit.Comment restaurer une sauvegarde .backup1 sur mi téléphone ?
Pourquoi ma sauvegarde est-elle divisée en fichiers .backup, .backup1 et .backup2 ?
Comment extraire les données sur un PC Windows ?
Un fichier .backup1 est-il chiffré ?
Est-ce la même chose qu'un fichier .ab de sauvegarde adb ?
.ab provient de la commande adb backup et stocke les données par application. Une partie .backup1 est une tranche d'une image brute de partition userdata créée par la récupération de l'appareil. Ils ne sont pas interchangeables.
