Best way to store data long-term (live through power cycles)

I'm making a DIY home control system using a raspberry pi as a broker and the ESP8266 (ESP-01) with MQTT to control lights and other stuff. I'm still in the development stage, but things are coming together. Currently I'm baffling over what to use to store things like device identifier and wifi credentials. I'd like to set it up so that if it can't connect to wifi (or the broker) it'll serve up a configuration page where the user can input that information. This obviously needs to be saved to long-term memory but I don't know if I should use EEPROM or some filesystem library. I'm also using OTA updates currently (ArduinoOTA) but that's subject to change.

My plan is to have an unconfigured device host a wifi network with a captive portal to enter wifi and MQTT broker credentials, which will get saved to long-term, after which it will restart and connect. Once it connects to the broker it'll ask for a unique name, which will also be saved to long-term on the device, as well as on the broker. This name will be used for the topics to control devices individually, instead of hard-coding individual topics. I'm using PubSubClient, which feels a little clunky when trying to differentiate topics and payload. Currently the supported topics are a restart command, a switch command (for switching a relay) and a color for the LED indicator. I'd like to have two (or more) devices running the exact same sketch but able to respond individually through configuration.

Given that this is really quite simple (the ESP is only switching a relay and changing the color of a WS2812b LED) I'm not overly concerned with things like efficient use of memory and power, it'll be plugged in all the time. Another idea I've had is to have the topics be the same across devices, but use a JSON payload to specify a device (with the name). I don't know if that's bad practice, since to switch a single light I'd be sending a message to all of the devices, but that seems like it might be a better way? I don't know. I've asked too many questions already.

(deleted)

I think you just totally changed the way I’m thinking about this project. Thank you, honestly more for the struct advice than the EEPROM, but thank you for both. I will be doing research and rethinking things over the next few days.

HaLo2FrEeEk:
I think you just totally changed the way I'm thinking about this project. Thank you, honestly more for the struct advice than the EEPROM, but thank you for both. I will be doing research and rethinking things over the next few days.

While you are thinking, add several empty bytes to the struct for future changes and oops, I forgot type changes. That will limit the number of programs that have to be changed to make the modification necessary for just two programs.
Paul