Redo is recovery replaying log records against the data pages, and 3456 means a record's replay found the page in an unexpected state. The cause splits cleanly by where it happened, and the message's LSN details plus your restore history tell you which side you are on.

The common side during manual restore sequences, sequence problems: a log backup applied out of order, a skipped differential or restoring logs from the wrong chain after someone took an unnoticed full backup, all present as redo hitting pages that do not match the record. The fix is knowledge rather than repair: query msdb.dbo.backupset on the source server ordered by backup_finish_date, reading first_lsn and last_lsn per backup to reconstruct the true chain, then restart the restore from the full backup applying every piece in LSN order. Third party backup tools keeping their own catalogs cause exactly this when both they and native backups run, the msdb query exposes the interleaving.

The serious side, corruption: if the sequence checks out and 3456 still fires at the same LSN, the log backup itself carries damage or captured damage from the source, verified by RESTORE VERIFYONLY against the suspect file and CHECKSUM options on future backups. Paths from there in descending order of preference: restore the chain only up to the last log before the damaged one with STOPAT if the missing tail is acceptable for a reporting copy, pull the damaged backup file fresh from its original location in case the copy corrupted in transit or take a new full backup from the source and start a clean chain, the honest reset for a reporting database.

Since this is a restoring reporting copy rather than a wounded production database, the reset costs little: fresh full backup, new restore, then CHECKSUM on every backup and a periodic RESTORE VERIFYONLY in the copy job, so the next 3456 announces itself in the job log rather than mid restore.