You need to reindex, which takes 3 to 5 hours and rebuilds chainstate

A clean shutdown in the middle of IBD will write chainstate to disk. Then if you backup chainstate plus the most recent BLKnnn.DAT, you have a checkpoint where chainstate is synced as at the most recent block in that BLK file. This assumes none of the older now-closed BLK files ever gets corrupted. Chainstate is about 12GB and BLK files are never bigger than 128MB, so it's a fairly light backup

Some notes:

The lopp.net blog has some articles on sync speed

If you have 16GB RAM do not allocate all of it to dbcache. I allow 1.2GB for OS and other functions, and I don't use GUI. This means set dbcache to 14800

I've only ever used HDD
With 4GB RAM and an I3 CPU, I set dbcache to 2800 and the IBD took 12 days
With 8GB RAM, I set dbcache to 6800 and the IBD finished in 55 hours
With 32GB RAM, I set dbcache to 16000 and the IDB finished in 16 hours
I have 2 HDD. It is faster to have chainstate on one HDD and blocks on a different HDD
According to the documentation, dbcache can't be more than 16000
Speed is best monitored as transactions per minute/hour, not blocks
I never use the GUI
Blocks are only written sequentially, never updated after closing each BLK**.DAT
Chainstate is constantly inserted and deleted. Using bigger dbcache (up to 16GB) stores more of chainstate in RAM, reducing the time-consuming insert/delete writes to disk
IBD does not verify txinput signatures if "assumevalid" is enabled, until the most recent blocks. IBD slows down a lot when it gets to this block, but by then it's nearly finished

Things not yet tried ...
Chainstate is about 12GB, so it would be cheap to use a small SSD for chainstate and keep blocks on HDD

...

Actual numbers are useful, but few people bother to make measurements. This means the generic "get a SSD" advice is based in ignorance
The biggest determinant is dbcache. One of the recent lopp.net articles has some measurements
Most people asking about slow node initialization do not specify how long it's taking, or what they expected, do not mention how much RAM they have, and never mention dbcache
Most "how to" articles fail to mention the initialization time. This is because most of those bloggers never actually finish the IBD, and do not admit it

It definitely means you can not open it in a text editor

Nonsense. It is a Berkeley/DB file, not a text file

During the long price fall in 2018, the mining hash rate fell sharply. The hash rate fall was delayed 6 months relative to the price fall

I was once told, by someone who was involved in making this work, that most pools build 2 blocks in advance, by predicting which transactions are not going to be mined, and constantly update these predictive blocks

This mechanism was developed collaboratively in 2016, by several pools, and improved iteratively to reduce the incidence of invalid blocks

The issue with the delay at the start of mining a new block is not verification. It is ensuring that the candidate block does not contain any confirmed transactions. A pool can not build a candidate block from the mempool without removing the just-confirmed transactions from the mempool. But the pool can guess with a reasonably high certainty, by choosing lowest-fee-rate transactions for its initial candidate block

And then after 50 seconds or so, the pool replaces the initial block with a fee-optimized block

Jameson Lopp reviewed empty blocks a few years ago
https://blog.lopp.net/empty-bitcoin-blocks-full-mempool/

In that review, only ViaBTC was mining empty blocks, which implies all the other pools had implemented the next+2 mechanism
More recent observations indicate that other pools are now mining empty blocks

I read the GitHub comment about file corruption caused by deleting the wallet file from outside the app. I don't see how it fits this story. TAILS is amnesiac, all files are deleted on shutdown, so that bug could only affect a wallet created within a TAILS session. The workflow - create wallet, write seed phrase, copy & paste address to Windows Electrum, send transaction - would have to be fairly contorted to write the empty wallet's seed phrase and copy&paste the other wallet's address. Maybe I'm overthinking, and the out-of-app file deletion is exactly the contortion which would cause this

There is also his claim that he successfully restored the wallet with seed words in TAILS before installing the Appimage. I'm inclined to believe this. If it's true, then the file corruption problem is irrelevant, whether it occurred or not

I suggest the seed phrase he's using now is from a fresh wallet created with the 3.3.8 Appimage, an empty wallet. The seed words for accessing the coin in the older version Electrum wallet are somewhere else, or lost. This contradicts his claim that he has the right seed words. In the absence of proof and 19 months passage of time, it's more likely than any other guess, in my opinion

Some notes from memory ...

Around the time of this transaction, Electrum users were being phished using the (previously) built-in server-to-client messaging function. The initial response to this was to remove the messaging function. Some users didn't upgrade, continued to suffer from the phishing problem, so there was a decision to configure Electrum servers to refuse to connect to clients older than 3.3.4, to force users to upgrade

TAILS does not update very frequently, so there was a period where the Electrum built-in to TAILS was unable to connect to servers. Also, the Python source of the post 3.3.4 versions required a later Python version than available in TAILS. A "binary" Electrum package (Appimage) was built and made available, and then (at least in Reddit) it was repeatedly promoted as "How to run Electrum 3.3.8 in TAILS", with instructions

Eventually, a later TAILS update had the necessary versions of Python and Electrum

Welcome back
Many thanks

That's horrible bad news
You were the only source which included a full chainstate
The other person only has the Blockchain
Good luck restoring service

Web server currently offline

https://getbitcoinblockchain{dot}com
Failed to connect to getbitcoinblockchain{dot}com port 443: Connection refused

EDIT: Now getting an almost-empty HTML page