Seeing that the recovery model is set to simple and msdn states that the simple recovery model does not support point-in-time recovery - Does this mean that I won't be able to use my transaction log backups to restore the database in a disaster to an hour before it happened?
Even taking a transaction log backup is not supported for databases using the SIMPLE recovery model. This is a restriction of the database engine based on how this recovery model works, and the recovery features it doesn't support, as you mentioned.
A transaction log backup maintenance plan task automatically skips databases in SIMPLE recovery to avoid causing errors.
Which backup should be done first, the database backup or the transaction log backups? Articles that I'm busy reading say I should do the database backup first and then the transaction log backup else I will get maintenance plan errors, but I'm currently first backing up my transaction logs and then data databases and I'm not getting any errors.
For the reasons I mentioned above, it won't matter for databases using SIMPLE recovery, as they will be skipped by the transaction log backup task.
For databases in the other two recovery models, a full backup must exist before you start taking transaction log backups (just the first time), or you will get an error -- this is probably what the articles refer to.
Point-in-time recovery ability is normally driven by business need -- in other words, you determine how critical the data is and how much you can afford to lose, then set the appropriate recovery model to meet those needs, and finally create a backup solution.
Even though SIMPLE recovery does not support point-in-time recovery, if an hour of data loss is okay, perhaps a differential backup solution could work for you. (There are far too many variables that go into developing this kind of solution to give you a complete picture with what was provided in the question.)
If you were trying to restore a user database - this would restore alright. The problem is that this is a system database. The system databases are designed for the version of SQL they were intended to work in. In order for SQL Server 2008 R2 MSDB to work in SQL Server 2012, you'd have to have no features different between the two versions. Make sense?
The Short Answer
To bring your jobs across, you'd script them out from the old server and apply the script on the new one. You can do this as simply as right clicking and scripting each job if you have a few. Or looking into a script with PowerShell or some other approach if you have a ton and don't want to one at a time.
To take the Logins you'd use the Sp_help_revlogin script I reference below and a script to copy server level roles and permissions from the old and copy them to the new..
Basically for 90% of what you'd bring across, I'm pretty sure the answer is "script it out" and then just apply that script on the new server and the logins, the jobs, etc. will all now live in the Master and MSDB databases designed for SQL Server 2012.
The slightly longer answer and a quick discussion on approaches to migration/upgrade
So if you are trying to transfer all of these objects to SQL Server 2012 you have two basic options on your approach.
- Do an in place upgrade. Upgrade your instance from SQL Server 2008 R2 to SQL Server 2012..
Pros - you get all that 'stuff' (agent jobs, linked servers, logins, alerts, operators, mail profile, etc.) and you don't have to copy objects around..
Cons - it can be a bit messy, it works fine nowadays and is supported but I am paranoid and like to know for sure that I have success and a quick rollback option (if issues on new server, just revert back to your old server during a migration. With an in place upgrade, it is much more, well, final).
You can start here for an in place upgrade.
- Migrate to a new server...
In this case you just flip the pros and cons from above.. The approach isn't that tough or strenuous. It just requires some good planning. Basically you:
On your old server, script out all of the objects you want to move according to the instructions and approach for each object type which can typically be found in Books Online (objects like Jobs, Linked Servers, SQL Agent Alerts, etc.)...
Use a tool like sp_help_revlogin to move your logins across and a script kind of like this to move the login permissions across..
Backup and restore your databases which already contain the in-DB users and permissions(I like doing this over detach attach because it helps preserve that rollback ability but I've seen and done this either way).. Change your compatibility mode if you are planning on supporting the DBs in 2012 mode and have tested them that way. Or keep them in 2008 mode if that was your plan.
Run those scripts for all of the objects like jobs, logins, etc. on the new server that you created above from the old server(good to do most of these after the DBs.. as logins will error on you if their databases that they default to aren't there or a T-SQL step in a job's database isn't there, etc.)
The other nice thing about this approach is you can do a trial run ahead of time during business hours.. Point a test or dev version of the app(s) used on that instance to the 2012 and see what breaks.. Fix it and test out your checklist, your rollback plan, etc. and do that prep for go live night.
Best Answer
Based loosely on Example E in the documentation, open a new query window and run:
The logical names are not important; the physical file names are. This makes assumptions about your logical file names and that there are only two; run
EXEC MyDB..sp_helpfile;to be sure.If you need to restore logs, then change
RECOVERYtoNORECOVERY:Then you can issue a series of:
And on the very last one:
Or if you only need part of a log up until a point in time (I assume you've checked where the LSNs and times are so you know exactly which files you need):
The way you said worked in previous versions would never have worked, unless the backup came from a different server. By default it will try to put the new mdf and ldf files in the exact same place, and this isn't possible.