I have depended on log shipping for a lot of my career. Often I've found the most common disaster is some user wrecks a lot of data. They drop or delete a table, they change all values to some scalar, or perform some similar problematic update. In those cases, it's often that a restore of some sort is needed, but we don't want to overwrite all the other data in the table.

While there are complexities in how you actually work with log shipping, pause it, recover data, and restart it, the basic idea is very simple. It's an extension of basic backup and restore, something all of us (should) be comfortable with. Perhaps that's why it's been something that homegrown scripts handled for many years.

In recent versions, Microsoft has added better tooling around log shipping, and there's a good piece on the useful ways log shipping helps DBAs, along with a feature request. The request is for the direct seeding of log shipping, similar to how Availability Groups can be created. While I'm not sure I love this idea, in today's world of high bandwidth, perhaps this isn't a bad idea.

For me, I think log shipping is a simple feature, but one that certainly could benefit from some ergonomic tooling that might help us better allow clients to discover our secondary databases, or ease the process of recovering data from them and returning it to the primary. I'd like better statistics to help administrators understand the rate of data transfer, easily learning if there are potential issues with our configuration.

Perhaps there are other features you'd like. Maybe you'd want some better filegroup restore capabilities added, allowing you to update some data, while other data is always available on the secondaries. Put on your thinking cap, brainstorm away and give us your ideas in the discussion below.