Eleven years of messages up in the air: the WhatsApp backup that could not be restored
WhatsApp series, 1/2. This article tells what happened to me when I changed phones. The second one, Is WhatsApp really secure? The problem of the endpoints you don't control, explains why end-to-end encryption does not guarantee everything it seems to.
TL;DR — I don't have time to read such a long text right now
- In January 2024 I bought a new phone. WhatsApp was unable to restore my backup: 1,701,082 messages, going back to November 2012.
- The restore reached "Finishing 99%" and failed. Every time. On three different phones.
- The official Android-to-Android transfer feature failed halfway through and left the old phone's database unusable. There was no going back.
- I spent 44 days without WhatsApp, because starting from scratch meant giving up the history forever. Support told me so themselves: the old history and the new one cannot be merged.
- I wrote 32 emails to support. I received 31 replies: 30 canned or automated, and one from a human being. That human promised to pass the case on to the Product team and never wrote again.
- What saved me was being a software engineer. With a rooted phone I captured the key, which WhatsApp keeps on its own servers and only writes to the phone for a few moments during the restore. With it I decrypted my own backup. All the messages were there.
- According to support, the database was "corrupt". In reality it had one duplicate row in a metadata table of 57,658 rows. Three standard SQLite commands clean it up in about 22 seconds.
What happened
I have been using WhatsApp since 2012. I have changed phones several times and it had always worked the same way: you install the app, verify your number, tap "Restore", and the Google Drive backup goes back where it belongs.
In January 2024 I moved from a Xiaomi Redmi Note 9S, which I had used for four years, to a Google Pixel 8. This time the restore did not work. It downloaded the gigabytes, showed "Restoring", reached "Finishing 99%", sat there for a while and ended up saying it could not restore the chats. Later on, the app simply died.

18 January 2024, 17:59: the restore stuck at «Finalizando… (99 %)». I have masked the Google account.

18 January, 19:10: «No se pudieron restaurar tus chats desde esta copia de seguridad».
Before doing anything else, I used adb to copy the whole WhatsApp folder from the old phone to my computer: about 30 GB in 80,000 files, including the daily local database backups. That precaution is, in the end, what saved everything.
I did what the manual says, and a little more:
- I deleted the Google Drive backup so the old phone would make a new one. It took about six hours and finished without a single error.
- I factory-reset the new phone.
- I reactivated WhatsApp on the old phone every time the new one failed. The first thing it did was update the backup, and I never interrupted it.
- I waited up to 20 hours between attempts, because WhatsApp's servers do not want you verifying your number that many times in a row.
Then I discovered that WhatsApp had recently added a direct Android-to-Android transfer over Wi-Fi. It looked like the solution: it did not go through Google Drive. The two phones found each other, the transfer started, and halfway through it failed. At that moment, WhatsApp marked the old phone's database as invalid. I could no longer use it. From then on, restoring the backup gave the same error on the old phone as on the new one.
It was 18 January 2024. The last message of my old history is from that day at 10:07. The last Google Drive backup is from 10:49: 20.5 GB, photos and videos included.
Why not just start from scratch
Because there was no way back. WhatsApp's own reply of 16 January says so:
"You can only restore your WhatsApp history before activating the app on the new device. [...] It is not possible to merge the old history with the new one."
If I tapped "Skip" and started using WhatsApp, I was giving up on restoring the backup forever. That is why I went without WhatsApp while I waited for a solution. It was 44 days, from 18 January to 2 March 2024.
On 2 March I made a final attempt, on the old phone. At 11:16 it failed exactly as it had six weeks earlier. That time I tapped "Skip" and started a clean account, with no history.

2 March 2024, 11:16: the same backup from 18 January, the same 99 %, the same error.

Figura 1
Even today, the app I use to read my messages shows two "incarnations" of the same number: the old history, recovered, and the new one, which starts on 2 March. Between the two there is a 44-day hole.
Invisible to everyone else
There was an extra kind of distress I hadn't expected. Almost everyone assumes that if you have WhatsApp, you always have it. Nobody checks whether a message has arrived: you send it and that's that. For those 44 days, as far as everyone else was concerned, I still had WhatsApp.
One example. A technician I had to meet about something for an association, far from home, phoned me one day to arrange to meet the next morning at eight. We agreed on it over the phone. The next day I turned up and he said: "Oh, I sent you a WhatsApp this morning to cancel." He hadn't noticed that the message never reached me. To him, it was unthinkable that someone might not have WhatsApp.
It's not surprising that people don't think about it: losing WhatsApp is unusual. But that is exactly why WhatsApp should say something. The sender only sees a single grey tick, the same as when your phone is switched off for a while, and no warning that the account hasn't received anything for weeks. Besides, WhatsApp only keeps undelivered messages for 30 days. I went 44 days without being able to read any of them.
Support: 63 emails and not a single engineer
Between 16 January and 5 March, 63 emails went back and forth: 32 mine and 31 from WhatsApp. WhatsApp's replies, classified:
| Reply | Times |
|---|---|
| "Larger backups will take some time…" | 4 |
| "Send us a video / a screenshot" | 4 |
| Satisfaction survey | 4 |
| "It looks like your chat database is corrupt" | 3 |
| "Reproduce the problem and send the logs" | 2 |
| "Your account is active and shows no problems" | 2 |
| "Uninstall, reinstall and tap Restore; we cannot help you" | 2 |
| Instructions for moving from Android to iPhone | 1 |
| "Update Google Play Services" | 1 |
| You cannot make a backup from WhatsApp Web | 1 |
| How to restore a local backup by renaming files | 1 |
| Marketing about end-to-end encryption | 1 |
| "We don't have enough information" / "send us your number" | 2 |
| "We did not receive the attachment" | 1 |
| Automated acknowledgement of receipt | 1 |
| Reply from a person who actually read the case | 1 |
A few moments that sum up the experience:
- 18 January, 19:22. I send a report with logs and screenshots from inside the app. Two minutes later: "It appears you need to update the Google Play Services app."
- 22 January. They tell me the database is corrupt because of "an interruption during the backup creation process" or because "WhatsApp was force-closed". I had done neither. I ask them, literally: "Am I being served by an automated AI system?" The answer is the same corruption template, word for word.
- 29 January. I ask for the only thing only they can do: give me the key to decrypt my database, or decrypt it for me. The one human reply of the whole exchange arrives. It says the case is being passed to the Product team, that the key "is not something we can share", and that some people have managed it with rooted phones, "but it is clearly not something I would advise". It promises to write back with news. It never will.
- 13 February. Twice they tell me my account is active and has no problems. They ask for my phone number, which was in every log they had made me send. When I ask whether the Product team has looked at the case, in less than a minute I get the "uninstall and reinstall" template.
- 19 February. I offer to pay for technical support if necessary. They ask for a video. I upload it to YouTube: you can see "Finishing 99%" and the app dying. Four minutes later they reply that large backups take time to download.
- 1 March, 12:12. I ask again for them to decrypt the local database. Reply: an explanation of end-to-end encryption, with the line that "nobody else, not even WhatsApp" can read the messages. I was not talking about messages in transit, but about a file on my own disk encrypted with a key of theirs. (That confusion is what the second article is about.)
- 1 March, 13:00. They ask for the video again, this time as an attachment. Their server bounces it because it exceeds 20 MB. When I explain this, they tell me they did not receive it and that the limit is 100 MB.
- 4 March. I write three times in a row that I need a human being to handle this. I get "corrupt database", "we already answered your question" and "larger backups will take time". WhatsApp's last message, on 5 March at one in the morning, is a satisfaction survey.
The replies came from seven different ticket numbers. Each one was a new ticket, with no history of the previous ones. That is why they kept asking, over and over, for information they already had.
I posted the case on Reddit. There I found out I was not the only one, not by a long way.
What my backup actually contained
On 13 March 2024 I obtained the key (I explain this further down) and decrypted the 18 January backup. Here is the data.
All the messages were there. It came to 1,701,082 messages, from 16 November 2012 to 18 January 2024 at 10:07. Decrypted, the file is 1.94 GB of SQLite.
There was one inconsistency, but a tiny one. SQLite's integrity check (PRAGMA quick_check) says some indexes do not add up. The cause is a single repeated row in the user_device table, which stores which devices each contact has — a table specific to multi-device WhatsApp. It has 57,658 rows, and one of them is a duplicate that violates a UNIQUE index. The messages have no problem at all. Indexes are derived data, like the index of a book: if they go out of sync, they are regenerated from the content.
I tested it on a copy:
DELETE FROM user_device WHERE _id = 215478; -- la fila duplicada
REINDEX;
INSERT INTO message_ftsv2(message_ftsv2) VALUES('rebuild'); -- índex de cerca
PRAGMA quick_check; -- okThat is about 22 seconds on an ordinary computer, and quick_check returns ok.
The logs WhatsApp itself made me send say:
msgstore-manager/checkhealth no db;
exception=android.database.sqlite.SQLiteException: Unable to open writable db: failed to open db
I cannot prove that the duplicate row is the cause of the failure: I do not have WhatsApp's source code. But it is the only anomaly I can find, and support's theory does not hold up:
- It was not an interrupted backup. A backup cut off halfway gives you a truncated file, and authenticated encryption (AES-GCM) would reject it on decryption. My file decrypts perfectly.
- I did not write that duplicate row. Without root, only WhatsApp writes to that database. The inconsistency was created by the app itself.
- The backup did not detect it and the restore did. WhatsApp was generating and uploading, every day, a backup it would not itself be able to restore, while saying everything was fine.
The curious case of the 1000 MiB
There is another coincidence I spotted before recovering the key. The daily local backups from the preceding days were:
| Backup | Bytes | MiB |
|---|---|---|
| 13/01/2024 | 1,044,519,996 | 996.1 |
| 14/01/2024 | 1,045,799,515 | 997.4 |
| 15/01/2024 (06:35) | 1,045,985,048 | 997.5 |
| 15/01/2024 (13:43) | 1,045,523,278 | 997.1 |
| 18/01/2024 (the unrecoverable one) | 1,048,578,748 | 1000.003 |
The backup that could no longer be restored is exactly 1000 MiB plus 2,748 bytes. Landing by chance within less than 3 KB just above such a round number is highly unlikely. It could be an internal size limit mishandled somewhere in the restore process. I cannot prove that either.
I wanted to check whether the duplicate row was already in the 15 January backups, when they had not yet reached 1000 MiB. I could not: the key I obtained in March does not open them. Between 15 and 18 January the key changed, probably when I deleted the Google Drive backup and WhatsApp generated a new one. My local backups from before that date are, today, files I cannot read.
Whatever the cause, both are WhatsApp bugs. If there is a size limit, the backup should say so when it is created, not when you already need to restore it. If it is the duplicate row, the restore could repair it in seconds, or the backup could detect it.
The key that "cannot be shared"
WhatsApp's local database and the ordinary Google Drive backups (the ones that are not end-to-end encrypted) are encrypted with a key the user does not have. On a phone without root you cannot read it.
On 13 March 2024 I installed WhatsApp on a rooted phone, verified my number and captured the key: a 158-byte file (I explain how next). With that key I decrypted the backup made by a different phone on 18 January. That means the key does not live on the phone: WhatsApp keeps it on its servers and hands it to any phone that proves it controls the number. That is what makes it possible to restore on a new phone without any password. The people who build forensic tools document this too: Elcomsoft explains that the key is generated by WhatsApp's servers the first time a backup is made.
So when support said the key "is not something we can share", it was literally true: they had it, they hand it over automatically to the app, but not to the person who owns the data. The app on my phone could read my history; I could not. This is exactly the question raised in the second article: whose endpoint is it?
Giving it to me would have cost them nothing. WhatsApp already hands the key over automatically to any phone that verifies my number, with the two-step verification PIN if it is enabled. Offering it to the person with exactly the same checks would add no risk: whoever can restore my backup on a new phone can already read it. It would be a button in the settings. In fact, with the end-to-end encrypted backup and its 64-digit key, they already accept that the user holds the key. For the normal backup, they simply don't offer it. Why, I don't know. It may be to save on support, to avoid making it easy for someone with your unlocked phone to walk away with your history, or to avoid making it easy to leave the platform. These are guesses.
How I got it
The key never shows up on an ordinary phone. What I did was repeat the restore on a rooted phone and watch WhatsApp's private directory, /data/data/com.whatsapp/, where no other app can look.
During the restore, WhatsApp writes the key to a file in that directory, because it needs it to open the backup. When the restore fails, it deletes it. There is therefore a brief window during which the key is on disk. With root, I was able to copy it in that window.
From there, the rest is well-known engineering. The crypt14 file is a header, a zlib-compressed SQLite database encrypted with AES-GCM, and an authentication tag. There are free tools such as wa-crypt-tools that, given the key, decrypt it. I ended up with a 1.94 GB SQLite database containing my entire history.
Recovering is not restoring
But having the data did not give me back my old WhatsApp. There is no official way to tell WhatsApp "this is my database, import it". And even if I re-encrypted it and put it back in place, WhatsApp would crash at the same 99%.
A nearly 2 GB SQLite database is also not an interface for reading conversations. That is why I ended up building my own viewer, which reads the recovered history and the new one as if they were a single one, and marks the 44-day hole between them.
WhatsApp did not lose my data. It lost the ability to give it back to me.
What we would ask of any backup system
Anyone who has administered systems knows what a backup must be held to. WhatsApp meets almost none of it:
| Usual property of a backup | |
|---|---|
| Making a backup whenever you want | Yes, with the "Back up" button |
| Incremental backups, with versions to go back to (yesterday, a week ago, a month ago) | No: a single cloud backup and a few rotating local ones |
| Verifying the backup's integrity | No |
| Doing a test restore without losing anything | No |
| Restoring only part of it (one chat, up to a given date) | No: all or nothing |
| Reading the backup with other tools | No: WhatsApp holds the key |
| Freezing changes to get a clean cut (the database quiesce) | No: you cannot stop incoming messages |
| An error that tells you what went wrong | No: "your chats could not be restored" |
| Someone who can step in when everything fails | No |
The conclusion is harsh but exact: with WhatsApp it is impossible to change phones with any confidence that you will not lose anything. You can reduce the risk, for example by putting the old phone in airplane mode before the final backup. But there is no way to freeze the account while you migrate, nor to check that the backup will restore before depending on it. Every phone change is a jump without a net.
The shortcomings of WhatsApp's backup system
Beyond my own case, the backup design has structural problems.
- There is no test restore. There is no way to check that a backup can be restored without actually restoring it, and restoring moves the account to the phone where you do it. You find out the backup is useless the day you need it.
- The backup says "all good" without verifying anything. The restore performs checks the backup does not. The result is backups that WhatsApp itself will not be able to restore, with no warning.
- The status the app shows can be false. I deleted the backup from the Google Drive website and WhatsApp went on saying there was a backup of so many gigabytes made at such a time. It was showing cached data, not the real state.
- The migration can destroy the source. The Android-to-Android transfer failed and invalidated the old phone's database. A migration should not touch the source until the destination works.
- All or nothing. If the restore fails on the last step, you get nothing out of it: no partial restore, no text export, no error message telling you what is going on.
- A single cloud backup. Each Google Drive backup replaces the previous one. The "restore an earlier backup" option asks you to pick a Google account, and on the very account I had just downloaded 19 GB from, it told me there was no backup.
- Local backups are of little help. WhatsApp keeps a few daily ones on the phone, but they are encrypted with the server's key. If the key changes, the old ones can no longer be opened. And restoring them requires renaming files and disconnecting Google Drive, a procedure that no longer even appears in the official help.
- The history cannot be merged. If you start from scratch because you need to communicate, you lose the option of recovering the history inside WhatsApp.
- Exporting a chat is not making a backup. The export produces text for reading or archiving, but it cannot be imported back to carry on the conversation on another phone.
- You cannot freeze incoming messages during a migration. Between the last backup and the activation of the new phone, messages arriving on the old one can end up outside the backup. There is no "hold the messages until the migration is done" mode.
- Support has no access to any engineer, or does not want to give it. Not even if you pay. The official help warns you already: WhatsApp cannot restore your chats because they are not on its servers, and cannot restore a corrupt backup. And the terms of service state that the service is provided "as is", with no warranties.

«Restaurar copia anterior»: on the very Google account I had just downloaded the backup from, «No se encontró una copia de seguridad». I have masked the address.
On top of that, the backup has limitations worth knowing about:
- Messages and media go separately. The
msgstore*.db.cryptXXdatabase holds the messages and the metadata. Photos, videos, audio files and documents go in theMediafolder. A complete backup needs both. The upside is that media can be copied separately and put back: if names and paths match, WhatsApp displays them again. - A backup is a snapshot. If a message arrives while it is being made, it may be left out. In a migration, the cleanest approach is to let the old phone receive everything it has pending, cut off WhatsApp's network access (airplane mode or a per-app firewall), make the final local backup, and copy
DatabasesandMediaoff the phone. Whatever people send you afterwards stays pending until the new phone connects.
Not an isolated case
When I told my story on Reddit, in February 2024, I found out I was not the only one. Looking further, there are public accounts from other people, over the years, on Android and on iPhone. They are user reports: they don't say how often this happens or whether the cause is always the same, but they show the pattern repeats.
- The backup is found, downloaded, and not restored. An 11.2 GB backup that WhatsApp detects, downloads to 100% and then cannot restore, on a second phone too (Reddit, September 2026). Backups created "successfully" that then fail to restore (Google Drive Community, 2022, with 29 more people reporting the same problem; 2025; 2026). A 9.6 GB restore after which nothing shows up; among what was lost, a message from a mother who had died (Reddit, July 2026).
- A decade saved by local backups. Someone who nearly lost ten years of chats because the Google Drive backup was broken, and saved them with the old phone's files. Their complaint is the same as mine: only one backup is kept in the cloud (Reddit, August 2024).
- The official transfer that wipes everything. "Transfer Chats" fails halfway, Google Drive says there is no backup, and the old phone has already been logged out: seven years gone (Reddit, January 2026). It is the same sequence as mine.
- The good backup, overwritten by an empty one. WhatsApp says it is having trouble reading the chat history, "recovers" it empty, and the next automatic backup overwrites the good one (Apple Community, 2017, with 508 "me too").
- Same story on iPhone. An 8.3 GB iCloud backup, with chats since 2012 with parents who have since died, and WhatsApp says there is no backup, on another iPhone too (Reddit, April 2025). Chats restored, but 14 GB of photos and videos missing (Apple Community, 2020).
The 99% is a known bug. The "Finalizing 99%" that happened to me shows up year after year. In 2021, WABetaInfo, the site that follows every WhatsApp release closely, was already explaining that on Android restores often got stuck at 99% (May 2021). Months later, writing about restores stuck at 100%, it added that a year on the cause was still unknown and users had no choice but to give up and lose their entire chat history (October 2021). There have been waves. In June 2023 the app forced users to restore and then hung (Hacker News; Canaltech). In February 2025, on Galaxy S25 phones, restores kept "failing at 99%" (XDA). In March 2025, heise reported numerous complaints about Google Drive restores that never finished, with the risk of losing chat histories, photos and videos (also on Italian and German forums). On iPhone, a 2023 update made it impossible to restore from iCloud and was fixed without a word in the release notes (WABetaInfo). As late as 2026, an editor at the Spanish site Xataka wrote that WhatsApp's backup "doesn't always work properly and is prone to errors (it happens to me often)" (Xataka Móvil). And when it fails, Google and WhatsApp pass the buck: to a user stuck at 99%, a volunteer expert on the Google Drive forum replied that they cannot help restore WhatsApp backups (Google Drive Community, 2023).
The backup is not always the problem. During the 2025 Galaxy S25 wave, Samsung's global community manager told users that WhatsApp was aware of the restore problem on those phones and working on a fix (Samsung Members Brazil). One user there explained that the restore failed at 49% and they had lost everything. In August 2026, someone found that the same Google Drive backup that kept failing on an S25 restored without trouble on another phone (Samsung Members India). In other words, "your backup is corrupted" is not the only possible explanation, however much it is the canned answer.
In Brazil, it took the courts. In 2023, a court in Curitiba ordered Facebook to pay a user 3,000 reais over a WhatsApp backup failure and to recover the data within 15 days (Migalhas). In 2021, the São Paulo state court had ordered Apple to pay 5,000 reais to a user who lost their WhatsApp backup after an iOS update (MacMagazine). In 2026, a user in Rio de Janeiro complained on Reclame Aqui, Brazil's big consumer-complaints site, that the restore froze at 66% and that afterwards the backup was gone from both Google Drive and the phone. The lost chats included conversations with people who have since died. WhatsApp has not even replied (Reclame Aqui). Olhar Digital, a Brazilian tech outlet, summed it up: "There are no redundancies, let alone protection against failures. Once the backup is lost, there is no way to recover it" (Olhar Digital, 2024).
And it is not all anecdotes. WhatsApp's own help centre acknowledges that chats hold cherished memories and that losing them is distressing; that a backup can become corrupted and WhatsApp can neither restore it nor tell what caused it; and that the Google account keeps only one backup per phone number, with each new backup overwriting the previous one. Google's guide to moving WhatsApp to a new phone warns that WhatsApp does not guarantee that chats and data will transfer correctly. It also claims, though, that WhatsApp does not delete your data during a transfer and that nothing is lost if something goes wrong. In my case, and in the seven-year case above, that is exactly what happened.
There are also bugs documented by researchers. In 2019, Check Point found a message that sent WhatsApp into a crash loop and forced users to delete the group along with its whole history (The Register). It has been fixed, but it shows that a software bug can make history disappear for good.
What I would do now
- Enable the end-to-end encrypted backup with the 64-digit key, and keep the key. WhatsApp offers three options (passkey, password or 64-digit key); the 64-digit one is the only one where you hold the key yourself. With it, free tools such as wa-crypt-tools can decrypt the backup without asking anyone for anything.
- Take backups off the phone regularly. Database and media, keeping several generations and not letting WhatsApp decide when they get deleted. For example, with Termux, SSH and
rsync. That is what I have been doing ever since (see the next section). - Do not let any migration assistant touch the only backup you have. The old phone stays untouched until the new one works completely.
- Do not expect anything from support. In my case, the only person who read it promised something they did not deliver.
How I have it set up now
Since then, WhatsApp is no longer the only keeper of my history. I have the end-to-end encrypted backup enabled with the 64-digit key, and I hold the key.
Every time the phone makes a backup, normally once a day, this happens:
- A script on the phone (in Termux) copies the WhatsApp folder with
rsyncto a server of mine, a Raspberry Pi. Databases and media both go. Whatever disappears from the phone is not deleted on the server: it is kept aside. - The server decrypts the backup with my key and checks the integrity of the database (
PRAGMA integrity_check). This check would have caught the 2024 duplicate row on the very day it appeared. It is not a test restore inside WhatsApp, which is still impossible, but it guarantees the data is intact and readable. - It dumps the database table by table into SQL files and commits them to a Git repository. Every backup becomes a version: I can go back to any day, see what changed or recover a deleted message.
- It publishes the database schema, which changes with WhatsApp versions, to a public repository: rsalinas/whatsapp-db-schema. Each commit is a detected schema change.
- It refreshes a web viewer of my own, where I read my whole history, the recovered one and the current one, without depending on the WhatsApp app.
- It emails me the result: "done" or "failed".

Figura 2
The properties from the table above that WhatsApp does not offer (versions, verification, reading with other tools, partial recovery) I have had to build myself. I am not publishing the code, but anyone with a bit of Linux can reproduce the idea.
With this system, WhatsApp could take away my ability to make new backups tomorrow: change the format, withdraw the 64-digit key option or close my account. But what I have already downloaded is mine. Over my own history I finally have sovereignty.
And it is not just peace of mind. That data has proved useful for many things. With the help of an AI I built an application that lets me query my message store in many ways and produce AI-ready dumps, so I can ask for summaries of a conversation, a group or a period.
Conclusion
WhatsApp came very close to making me lose eleven years of conversations: with family and other loved ones, with friends, work-related, from associations. A messaging history is no longer "data": it is personal correspondence, voice notes, photos, memory. When what disappears are the messages of someone who has died, researcher Debra Bassett, who studies grief and digital legacy, calls it a "second loss" (The Conversation).
It was not an accident of mine. The cause was a chain of bugs in their software: a backup that was never verified, a restore that died at 99%, a migration that destroyed the source, and a support service that did not listen.
I recovered everything because I know how to root a phone, capture a key and read a SQLite database. Most people do not. For most people, this story would have ended on 2 March with an empty account and the conclusion "I lost eleven years of WhatsApp". If the data exists but only a specialist can recover it, to what extent has the backup done its job?
The problem is not the encryption. That WhatsApp cannot read my conversations is a good property. The problem is that confidentiality and recoverability are different things, and the design sacrifices the second one needlessly: a verifiable backup, a test restore, a partial recovery or a key in the user's hands would not make the conversations any less private.
The data was always mine. The key was not.
Appendix: full timeline
Local times (Spain). "Me" means an email from me; "WA", a reply from WhatsApp. In bold, the events that are not emails.
| Date | Time | Who | What |
|---|---|---|---|
| 16/11/2012 | First message of the history that will be lost. | ||
| 13-15/01/2024 | Daily local backups; I copy the WhatsApp folder to my computer with adb. First attempts to restore on the Pixel 8. |
||
| 15-16/01 | Me | From the app: I cannot restore the backup on the Pixel 8; I deleted the Drive backup so it would be regenerated and I reset the phone. | |
| 16/01 | 09:55 | WA | Instructions for moving from Android to iPhone. "It is not possible to merge the old history with the new one." |
| 16/01 | 22:49 | WA | Satisfaction survey. |
| 18/01 | 10:07 | Last message of the old history. | |
| 18/01 | 10:49 | Last Google Drive backup (20.5 GB). The Wi-Fi transfer fails and invalidates the old phone's database. | |
| 18/01 | 14:40 | WA | "Reproduce the problem and send the logs." |
| 18/01 | 19:22 | Me | Report from the app, with logs and screenshots. |
| 18/01 | 19:24 | WA | Update Google Play Services. |
| 19/01 | 10:08 | Me | It is already up to date; it still fails. Could there be something the backup does not verify and the restore does? |
| 19/01 | 14:43 | WA | Large backups take time to download. |
| 22/01 | 09:20 | Me | From the app, in English: I still cannot restore. |
| 22/01 | 14:19 | WA | The database is corrupt (due to an interruption or a force-close). |
| 22/01 | 16:06 | Me | I did not interrupt anything. I offer the 30 GB copy of the phone's storage. |
| 22/01 | 16:11 | WA | You cannot make a backup from WhatsApp Web. "We cannot help you restore your chats." |
| 22/01 | 16:15 | Me | The copy is of the phone's storage. Can it be reused? |
| 22/01 | 16:22 | WA | "We already answered your question"; send a screenshot or a video. |
| 22/01 | 16:42 | Me | "Am I being served by an automated AI system?" Full account of events and a request for escalation. |
| 22/01 | 17:53 | WA | Corrupt database (same text). |
| 23/01 | 09:08 | Me | The account of events in English: "Please escalate this." |
| 24/01 | 09:21 | Me | I forward the account of events to the Android support address. |
| 25/01 | 14:47 | Me | From the app: can I send you the data so you can repair it? |
| 29/01 | 10:08 | Me | "Please decrypt my msgstore.db.crypt14": the key, or have them decrypt it. |
| 29/01 | 17:29 | WA (person) | Passes the case to Product. The key cannot be shared. Root is not advised. Promises news. |
| 29/01 | 22:20 | Me | Thanks. |
| 05/02 | 12:22 | Me | A week with no news; almost three weeks without WhatsApp. |
| 10/02 | 17:59 | Me | From the app, on the old phone: now the app dies. |
| 13/02 | 17:07 | Me | I try WhatsApp Business: the same error. |
| 13/02 | 17:10 | WA | The account is active and has no problems. |
| 13/02 | 17:58 | Me | The problem is that I cannot restore ten years of messages. |
| 13/02 | 17:59 | WA | What is the phone number? |
| 13/02 | 18:11 | Me | The number (it was already in the logs). All I ask is that they decrypt the database. |
| 13/02 | 18:14 | WA | The account is active and has no problems. |
| 13/02 | 18:15 | Me | "It feels like I'm being answered by an AI stuck like a broken record." |
| 13/02 | 18:16 | WA | Uninstall, reinstall and tap "Restore". We cannot help you. |
| 13/02 | 18:25 | Me | To the person from 29/01: has the Product team looked at the case? |
| 13/02 | 18:25 | WA | The same reinstall template. |
| 14/02 | 06:23 | WA | Satisfaction survey. |
| 14/02 | 06:39 | WA | Satisfaction survey. |
| 19/02 | 10:29 | Me | From the app: the restore dies. I am willing to pay. |
| 19/02 | 12:04 | WA | Send a video. |
| 20/02 | 21:20 | Me | The video, on YouTube. |
| 20/02 | 21:24 | WA | Large backups take time to download. |
| 20/02 | 21:33 | Me | Have a person look at it. I have tried on three phones. |
| 20/02 | 21:34 | WA | How to restore a local backup by renaming files. |
| 29/02 | I post the case on Reddit. | ||
| 01/03 | 12:12 | Me | Ten days with no reply. I link the Reddit thread and ask again for them to decrypt the database. |
| 01/03 | 12:14 | WA | Explanation of end-to-end encryption: "not even WhatsApp". |
| 01/03 | 12:17 | Me | Do not confuse encryption in transit with the local database's encryption. |
| 01/03 | 12:36 | WA | We don't have enough information: number, model, steps, video. |
| 01/03 | 12:48 | Me | They already have everything, including in the video. |
| 01/03 | 12:53 | WA | Send a video. |
| 01/03 | 13:00 | Me | I attach the video: their server bounces it (20 MB limit). |
| 01/03 | 13:11 | Me | So how do I send it? |
| 01/03 | 13:17 | WA | We did not receive the attachment; the limit is 100 MB. |
| 01/03 | 13:20 | Me | The video reduced to about 5 MB. |
| 01/03 | 13:38 | WA | Large backups take time to download. |
| 01/03 | 15:26 | Me | Logcat on a Xiaomi Mi A1: SQLiteException: Unable to open writable db. The file is 1,048,578,748 bytes: is there a size limit? |
| 01/03 | 15:28 | WA | Reproduce the problem and send the logs. |
| 02/03 | 10:54 | Last restore attempt, on the old phone. The pending messages start coming in. | |
| 02/03 | 11:16 | It fails once more. I tap "Skip": new account, no history. End of the 44 days without WhatsApp. | |
| 04/03 | 08:06 | Me | New logs, the 1000 MB clue and an offer to pay. |
| 04/03 | 08:07 | WA | Automated acknowledgement of receipt. |
| 04/03 | 11:04 | WA | Corrupt database. |
| 04/03 | 11:44 | Me | The backup was not interrupted. Is there a size limit? All I ask for is the key. |
| 04/03 | 11:48 | WA | "We already answered your question"; send a screenshot or a video. |
| 04/03 | 11:51 | Me | I need a person to handle this. |
| 04/03 | 11:57 | WA | Large backups take time to download. |
| 04/03 | 12:58 | Me | I need a person to handle this. |
| 05/03 | 01:05 | WA | Satisfaction survey. WhatsApp's last message. |
| 13/03 | With a rooted phone I obtain the key and decrypt the 18/01 backup: 1,701,082 messages. |