Although @Mark has answered this to the extent I'd consider acceptable, it remains unmarked so I would just add as an alternative explanation to the same point being conveyed:
Point of "Failure"
It seems that one of the weak points in LUKs encryption is that the
LUKs header can be a single point of failure if you do not create a
backup header for it.
First and foremost, to clarify the LUKS header being "a single point of failure" specifically refers to being able to access your data by way of entering a correct password and having the data decrypted. It is not necessarily a single point of failure in terms of security in and of itself.
Therefore preventing this point of failure in the sense that there's a fair chance the header could be corrupted either by way of accidentally writing data to the beginning of a block on a particular drive as part of a format or data transfer of some sort or a power failure that occurs when beginning to read from the drive and corrupting it that way. In either case, there's not a great need for concern of someone else recovering a backup of your LUKS header. With the header alone it doesn't give them access to your data, they would still need the password to the header and that's where greater concern should be placed: making a high entropy passphrase to be used.
My question is: What methods of securing your backup LUKs header do
you take to ensure it is not recovered by someone else?
None, if any. Your focus should be on securing your encrypted drive when it's not in use or if it's left unattended while unlocked on any given system.
A backup header by itself is useless and could only serve one 'usefulness' to an adversary if it's even considered useful when considering the "possibility" it enables. Which is, to run brute force attacks on trying to guess your password. Assuming you use a password longer than 8 characters with a fair amount of randomness and otherwise high enough entropy that it doesn't contain just one simple word that can be guessed but a fair mix of symbols, numbers, lower case, and uppercase; they could run that brute force for more than a century (with today's computing power) and still never figure out the password simply due to the sheer number of possible combinations it would be required to cycle through all the possible passwords that exist out there.
So, moral of the story, worry more about securing your data than securing a backup copy of your header and you'll be able to "secure it" in plain and clear sight, just so long as you put enough energy into a complicated, difficult to guess, password.
And if there's anything you should be doing to ensure you can actually use that backup, is to make sure you don't store it on the same encrypted drive it's meant for, because to replace a corrupted header, you'll need access to it and if it's in the drive that's encrypted and that won't open because you don't have access to the backup header to replace the corrupted one, should be obvious that it is self-defeating.
So, where to put the backup if not needing to hide them but you still want to anyway?
Well, you can still "hide" it if you want by creating an empty partition on any given device, such as a USB drive, an SD card, or an unformatted partition at the end of your drive (after the encrypted partition or before, doesn't matter except somewhere that it won't be accidentally written to) and write the header to that partition itself so it's hiding in clear and plain site. When backing up the header, you're no longer limited by the filesystem layer and can directly write the header to an empty partition space so that it just appears like an unformatted partition rather than a file that can be found by browsing through your various folders or whatnot... Kind of like, hidden in clear and plain sight .