While there are ways you could do this, it is fundamentally a bit at odds with the idea of LoRaWAN.
It’s easy enough to retain raw LoRa packets on a gateway where you control the software, the problem is that in the LoRaWAN architecture gateways do not have the keys to decode application or even network level traffic, and are both unable and unauthorized to autonomously reply to any confirmation-requested transmissions, not to mention anything having to do with adaptive data rates or over the activation (re)joins or housekeeping. Essentially gateways are all but stateless translators between MQTT and LoRa-modulated RF - they don’t actually “know” anything.
Even if your nodes do keep transmitting without any replies throughout the gap in backhaul service, a LoRaWAN server isn’t set up to ingest “stale” traffic, especially if it arrives out of order, since things like the anti-replay-attack frame counters would be broken. So if you have any other gateways that might have reported the occasional packet through on time, you would have to disable those checks. I’m not quite sure what would happen if you tried to feed in stale data with them disabled (easy enough to try at MQTT level, though now that I think about it, having had a gateway reboot and get reconnected to LoRaServer faster than it got a new NTP time fix, it looks like packets with stale times may actually be accepted if the frames are still in order)
Or you could decode the stale data from the gap periods yourself, by any of knowing the original secrets of ABP nodes, querying OTAA session secrets from the server API, or by knowing the original secrets and watching the raw join traffic.
Also as a comment on “cellular” (etc) modems: you may want to invest more effort in managing them. If things get really stuck, a task which ultimately gives up and reboots your gateway’s computer does not necessarily reboot the modem - ended up running a wire from a GPIO to be able to power cycle the modem (fortunately the SBC in use already had a USB power switch chip, but it was setup for overcurrent protection only, with the enable pin having only a pullup until we explicitly wired it to a GPIO). Some also have a reset pin which might work, but that was going to be harder to get at in our case.