For the sake of discussion, let's assume that there is a 30 minute delay (lag) in applying changes to the database on the DR server.
- 10:00 User deletes something they shouldn't have.
- 10:10 They call you.
- 10:20 You query the (as yet unchanged table) on the standby. You find the rows that they deleted and copy them into another table, port the data back to the primary database and re-insert them.
- 10:30 The log shipping "catches up" and the rows are deleted from the standby.
- 10:50 Thirty minutes after you put them "back" onto the primary, the rows get re-added to the standby.
All you've done is query a table into another table, ported that to another database and run another insert..select to re-populate the rows into the original table.
Let's face it; that's easy.
You would have to recover a copy of the database from a Point-in-Time [just] before they deleted the rows. Depending on the size of the database, that could take a while and, of course, you have to have the disk space on hand to do the recovery (you should have this on "hot-standby", just for emergencies).
Then you can do the whole insert..select, port, insert..select thing again.
That sounds "nice", but ... quick Reality Check.
Thirty minutes is an Eternity in computing time.
Having that much lag in your DR "loop" is just asking for trouble (although your Recovery Objectives might say different). Seconds, rather than minutes, is usually the order of business here. By the time the User has realised they've done something dumb, you'd normally expect the standby to be in the same, messed-up state as the primary.