Unanswered: Restore without restoring empty transaction log
Here is the problem description:
We have in production a database with huge log size (>20 Gb).
I'd like to restore this database on another server BUT there is not enough disk space to restore the log.
What we do now:
We truncate the log before the backup.
This isn't ideal since the transaction log has to grow again.
Do you have any suggestion how we could work without truncating the log?
Before taking the database backup change the recovery mode simple.
after changing the recovery mode you can shrink your DB logs.. by changing the recovery mode to simple can truncate your whole current database logs.. Now you can generate the database backup and restore it on diff. server.. here now you can configure auto shrink so that you need not delete your database logs manually. and you can save you disk space...
Changing to simple mode is not an option: these databases are mirrored and it is production (transaction logs are needed).
The shrink of the databases gives no problem. The truncate shrinks it to a reasonable size (so my problem isn't there).
The problem I have is that, since I've done a shink, I need to regrow the log file after the backup has been taken.
This is to prevent autogrowth during the day and it's easier to see the amount of space left on disk.
So If I could avoid to shrink it, it would save time/ressource usage/reduce disk fragmentation/avoid autogrowth waits.
I've very crudely tested applying snapshot replication, dropping the subscription and editing the database. This works.
This would, however, probably have a greater resource implication than shrinking and growing the log.
I assume this has already been considered and rejected, but have you got a slot for another disk? Apart from anything else, if my prod db has some large process that grows the log to 20GB then I would want my test environment to be able to handle that same process.