Encrypted files stored next to GPG Key in backup – alternative solution?

During a recent test run to see if my personal backups work as intended, I noticed that I store my GPG key next to files encrypted with that key on the same disk. Although the disk is encrypted (LUKS) and the key has a strong passphrase, this feels a bit wonky.

While having a second drive just for the key might improve the situation, it also feels a bit overkill. Hence I am looking for a more pragmatic solution. I thought about placing the key on a separate partition that is encrypted separately (with a different password of course), but I am not sure if it is a good idea.

1. Is it considered a bad practice to store key and encrypted files next to each other?
2. Will a separate partition improve the security in any significant way? It's still the same disk after all.
3. Are there any alternatives to that dilemma?

In reality, the key file is nothing more than a sort of "superpassword", so if, in turn, it has a sufficiently long password, I don't see any particular risks. I emphasize long enough: to expand the space of both a dictionary and brute force search it is much more important to have many characters, rather than a larger alphabet

1. Is it considered a bad practice to store key and encrypted files next to each other? In fact, yes

2. Will a separate partition improve the security in any significant way? In fact, no

3. Are there any alternatives to that dilemma? In some extreme cases USB tokens are used which are physically removed and inserted when required, sometimes with a second level of access (for example TrueCrypt/VeraCrypt container etc).

But I suggest, more trivially,a "long long" and strong password and a good symmetric cipher for backups.

Is it considered a bad practice to store key and encrypted files next to each other?

Yes, not ideal to put the key in the same place as the cipher text. For example, perhaps files on the open LUKS containers are archived and uploaded to the same object storage account, as a file based backup. An adversary paying attention will take the private key and attempt to decrypt with it.

A separate LUKS volume may be more secure to the extent that it makes the plain text less accessible. Only opening the volume for as long as you do GPG operations lessens the exposure.

In the real world, practical compromises are necessary. On disk keys are easy to use. Passphrase protected key slows an attacker from using it, but its only a matter of time. If a copy of a GPG private key is taken, consider it compromised. Consider rekeying.

Are there any alternatives to that dilemma?

Ideally, do not store the private key on an online storage. Use a smartcard hardware token for private key, YubiKey or similar. Store cold backups on tiny storage devices or paper keys, and put these a secure offline place, like the business continuity safe. Extraordinary measures, but secrets are special as they unlock other data.