I've worked in a few different capacities and have seen this happen, and seen previously excellent developers decide they simply couldn't take the pressure and head out for something easier. I can respect the latter and provided your interest isn't in attempting to "get away with pretending to work[0]", desiring a less demanding role somewhere else isn't something worthy of "flak".
Onto advice: I had a friend who worked at a shop that did high-end bespoke software centered around compliance management automation/assistance software for complex manufacturing operations. The company didn't have a product, but wrote a ton of software tying various things together, along with a 25% solution that they'd customize out for each customer. This guy wasn't the original author, but had become the SME for nearly the entire solution over about 8 years. He was a bit older than me; I think 45 at the time, had an unexpected fourth child, and effectively started looking like a train was hitting him every day.
I was working for a large telecom, at the time. I was not on their development team but was a full time developer[1]. Backend-only dev definitely exists depending on the languages you're writing in (though you'll probably have to write a line or two of JavaScript from time to time). Sysadmin work definitely exists at large companies; I know we had a large team (referred to as "Infrastructure") in various capacities (nix was broken into a few teams, CDN was its own group). I had worked with two of the Unix teams at various times -- by God, you'd be amazed* at how many things are done a command at a time. No scripts. I assumed it was some policy/fear/craziness. Nope, the manager of the team was a good friend so I asked him: entirely skillset.
There isn't enough background about your current job, so I'm not sure how close my recommendations will be to what you are already doing, however, I'd strongly recommend looking into the largest companies in semi- or non-tech sectors. Check they're IT ops/dev organization; note whether they're using a third-party[2]. If you want that "back-end only job", look no further. Our 7 or 8 most important systems served only massive global multi-nationals[3].
You'd be surprised how many organizations have large DBA teams. I'm not knocking DBA work; I've worked with great DBAs, but at a past job, all but one of the 6 member team did much more than run a commercial profiling tool, and add indexes from time to time. Bear in mind that every infrastructure job at the company I worked at had an on-call requirement which involved being willing to be awoken at any hour of the night for a week to remote-in for emergencies. It's pretty common to have an on-call requirement.
But let me tell you how I hope it turns out. My buddy took my advice and ended up getting an "Easy Corporate Job" -- in office, but with a promise of 3-days remote in 6 weeks. I remember him telling me that the job was so boring he finished all of his "daily to-dos" for the week in the first couple of hours on Monday, scripted half of them out his life and had the other down to a set of commands he could run to reduce the time required to complete.
He said "Duuuuude, this job is so easy. I work as hard in a week in this job as I did in a day in my last and my boss has never seen someone work so hard!" His burnout ended in a couple of weeks. His boss let him work from home "anytime he wants" at week 3. He never returned to working "his ass off" like he did at the last job, and he has been in the same position for years. He's made new friends on the team, who respect him for his abilities and his boss loves him -- I think partly because he's not using the team to step-stone into a better role. There really is a place for people who are OK staying where they are. That's not me, but I count several among my friends and I have enjoyed working with many who "handle their piece of the puzzle with expected results -- no more, no less"
It's been a decade, but I used to interview developers at big-corp. We used get the bottom of the barrel of the resumes. Nobody wanted to work for BigCorp "process-driven-agile-buzzword development shop". The thing of it is, I observed that the development shop[1] basically did everything that I've done at every dev shop I've worked at, since. But the "reason" they do the things (stand-up/retrospective/back-log and on and on) but instead of being used in support of Agile's goals, they're basically used as a kludge to reduce the amount of change that applications experience. Guess what that means for a large dev shop? They're all pretty bored.
I was under infrastructure in my role at at BigCorp (various levels, including under the CIO at once; it's not as cool as it sounds but it's fun to say). I saw how little was expected of those employees and steadfastly refused all attempts to move me there. I eventually left the company because I wanted to work on things that were more difficult/interesting and 90% of my co-workers "just showed up every day". And BigCorp will let you work remotely, even pre-pandemic, but it can be tricky and pulled out from under you from higher up, so the risk of a "Yahoo!" happening is pretty easy.
[0] Too often I've been on the receiving end of this individual, and because "at the end of the day the job has to get done", if your job is to pretend your job is important and pretend you're working hard, history has shown that I'll get the work, and you'll get in my way.
[1] There's a comment in my history explaining -- probably several -- but I was part of a small team developing software for internal infrastructure with full autonomy with regard to the technologies/choices I made, but had to write what was needed in the priority the company wanted it. I wanted nothing to do with the development shop for reasons that will become apparent.
[2] This isn't necessarily a bad thing; might even be good depending on how the arrangement is. I know of one support person at a large company who works through, I think, HP (maybe IBM?) supporting servers at a few datacenters. He's technically required to be at the DC in a few very limited circumstances (one of which is not "first-time setup", they're installed by another group), but he was working remotely well before the pandemic.
[3] Meaning, basically no e-commerce. You're managing an important ticketing system/status reporting service and a million custom internal apps for managing the business that were written a decade ago and Walter retired last year. We had a two-node web site running a Sybase back-end for our most important apps most of the time I was there.