In March, I made a backup of the wallet and continued using the node. In October, I restored my old backup. After restoring the backup, I found that the listtransactions command stopped displaying some transactions made during the period from March to October.

**Expected behavior**

The listtransactions command displays all transactions in the restored wallet.

**Actual behavior**

The listtransactions command in the restored wallet does not display some transactions since the backup.

**To reproduce**

1. Run bitcoin core in regtest mode
2. Create a new address A and generate 101 blocks with sending a reward to the created address A
3. Create a wallet backup
4. Create new address B
5. Send transaction to address B, write TXID
6. Generate 1 block with sending a reward to address A
7. View getaddressinfo B. Verify labels are not an empty list
8. View listtransactions. Make sure there is a TXID transaction present
9. Stop bitcoin core
10. Restore backup
11. Run bitcoin core
12. View getaddressinfo B and listtransactions. Detect that the address does not have a label set and that listtransactions does not contain a TXID transaction.

**System information**

Bitcoin Core 0.20.1 on Debian GNU / Linux.

virtual void SetMinVersion(enum WalletFeature, WalletBatch* = nullptr) = 0;
    virtual const CKeyingMaterial& GetEncryptionKey() const = 0;
    virtual bool HasEncryptionKeys() const = 0;
    virtual bool IsLocked() const = 0;
};
static const unsigned int DEFAULT_KEYPOOL_SIZE = 1000;
std::vector<CKeyID> GetAffectedKeys(const CScript& spk, const SigningProvider& provider);
/** A key from a CWallet's keypool
 *
 * The wallet holds one (for pre HD-split wallets) or several keypools. These
 * are sets of keys that have not yet been used to provide addresses or receive
 * change.
 *
 * The Bitcoin Core wallet was originally a collection of unrelated private
 * keys with their associated addresses. If a non-HD wallet generated a
 * key/address, gave that address out and then restored a backup from before
 * that key's generation, then any funds sent to that address would be
 * lost definitively.
 *
 * The keypool was implemented to avoid this scenario (commit: 10384941). The
 * wallet would generate a set of keys (100 by default). When a new public key
 * was required, either to give out as an address or to use in a change output,
 * it would be drawn from the keypool. The keypool would then be topped up to
 * maintain 100 keys. This ensured that as long as the wallet hadn't used more
 * than 100 keys since the previous backup, all funds would be safe, since a
 * restored wallet would be able to scan for all owned addresses.
 *