MIS Systems Thread, Sims Backup in Technical; Reading the really useful document that CAM linked to has answered my questions. It's so useful i think it's worth ...
Reading the really useful document that CAM linked to has answered my questions. It's so useful i think it's worth attaching here for those that can't be bothered to access SupportNet or for various reasons have no access or are not allowed access.
I recommend everyone to read this really useful document.
In short, regarding my queries:
A dbattach backup, does not move the logins into the mdf.
Previously moved logins, will stay in the mdf and are not cleared.
I don't think any of our users ever change their passwords unless they have forgotten them and I do it. So a once detached DB will pretty much have all logins stored within it apart from any new users. So there is no fear if you are using dbattach for backups, most users will be retained. The only pain is if your users regularly change passwords through choice or your enforcement.
SIMS must be backed up first, then FMS. Chaos will follow if not, come restore time - assuming your using FMS. dbAttach, I believe, doesn't transfer the logins when it backs up - it will. If your database is set to simple, the logs aren't an issue, but if your doing diff backups - ie the database is set to full, you'll need to truncate the log file if your using SQL maintainance task (after the backup of course!).
FYI: WinRar isn't free. Use 7zip or tidybackups.
Good to know about the order, not sure what order my maintenance task runs them in as i select all DBs in the dropdown. I'll have to check file times now!
Not clear on your point about dbattach backups, but i've confirmed it doesn't transfer logins.
I didn't think the log file was used anymore, or am i getting terminology mixed up again... I'm thinking about the ldf..
ldf (mssql logs) shouldn't grow if it's set to SIMPLE, but if your using something like RedStor, it won't be.
I'm moaning at Capita about the transferring of logins when you do a dbattach backup, I suggest others do as well, might be too late for Spring, but hopefully they can do it by Summer.
ldf (mssql logs) shouldn't grow if it's set to SIMPLE, but if your using something like RedStor, it won't be.
I'm moaning at Capita about the transferring of logins when you do a dbattach backup, I suggest others do as well, might be too late for Spring, but hopefully they can do it by Summer.
I understood, the ldf is not used anymore period, but i guess thats based on being in SIMPLE mode which is their recommendation right.
I've just been saying in another thread, about moving sims server, with GREED and others, that we should log a change request for dbattach backup to automatically do the logins transfer, and also have that command available as a command line option on it's own so it's more useful to us techs. Running the stored proc itself will never be acceptable by Capita but if they compile it into the utility we can all stay on the right side of the line
Here's a question.
I've used the all new fancy upgraded DBAttach to backup my db and the logins are transferred to the db.
I restore to brand new disaster recovery server A.
The logins wont work at this point, until i run the install procedure, right? Need to have that as an optional command on the DBAttach too.
What would happen if i just detach and then reattach the db in it's new location. I think that it would work, as that often fixes things for people, however if i had to guess i would expect that from a blank master the table in the mdf would be cleared / overwritten, as though it was being updated... views anyone..
SIMS must be backed up first, then FMS. Chaos will follow if not, come restore time - assuming your using FMS. dbAttach, I believe, doesn't transfer the logins when it backs up - it will. If your database is set to simple, the logs aren't an issue, but if your doing diff backups - ie the database is set to full, you'll need to truncate the log file if your using SQL maintainance task (after the backup of course!).
matt can you please expand more on this ordering business. i'm backing up both as part of the same maintenance plan, and fms being alphabetically first is running first by about 2 secs. The backup takes around 90 secs. What flavor of impending doom should i expect?
Also, who only weakly voted for the change request? Somebody doesn't really want the logins to work that badly ...?
So a simple dbattach to backup sims2008 and fmsmain will save me in case of failure ? Ive got it backing up then copying to the other side of the site then also doing a backup to a removable device for off site
So a simple dbattach to backup sims2008 and fmsmain will save me in case of failure ? Ive got it backing up then copying to the other side of the site then also doing a backup to a removable device for off site
In the simplest method yes that's correct. All you stand to lose is the user logins, but your data is safe. You should test your backup all the same.
To keep logins, firstly go and vote for the change request so this in included in the dbattach backup. Secondly, you have some options, either detach and reattach the db prior to every backup, or just do it once, and any changes after that will not be updated.
You could also manually run the stored procedure for transfering the logins, prior to doing the backup, which is what happens during the detach process.
The attachment earlier explains the finer intricacies, but in a nutshell the above is how it works. Hope it makes sense.
We use scripts provided by our LA support team (their recommendation) and from what I can tell all this does is backup the MDF files into the backup folder within MSSQL. From here these are then copied over in our backup procedure.
We use scripts provided by our LA support team (their recommendation) and from what I can tell all this does is backup the MDF files into the backup folder within MSSQL. From here these are then copied over in our backup procedure.
Is this not sufficient? :-S
I'm assuming it's a standard SQL backup and nothing else funky being done. In this case, you'll end up with a .bak file or maybe a .zip or .rar if they are compressing it after.
That is sufficient to back up your data, so don't worry. You will not lose any data, and in a disaster recovery scenario you'll be able to get it all back.
Unless you use dbattach to detach then reattach the database prior to a backup, then the logins will either not work, or be out of date. That's all.
Worst case you'd have to reset everyone's passwords.
Ok, so i just set up my new Win2k8R2 test box with SQL2k8R2 put on a basic SIMS install.
I logged in with the default SIMS sysman account, so there was definitely 1 working login. The only other logins in the system were the initial one created with a basic install, e.g. SLGuser, sims_teacher, sims_student, etc. By logins i mean actual logins listed in the SQL | security section.
I next restored my live sims server backup. It complained and threw an error about a massive list of users / logins not found in the system, some where it tried to fix by mapping to existing logins and all manner of other weird stuff. i couldn't see the end of the window or resize so i just had to close.
No logins had been created, however i was able to login with the sysman account, so i used this to go into the system manager and reset my own password. I actually chose to use trusted login and linked it to the local admin account as the box is not yet on the domain.
When i did this, i got an error about a user, my colleague, whose account is also using trusted authentication in my live system. i thought nothing of it, and closed the box. The change to my user had saved, so i carried on.
I logged in and started testing all was good.
When i looked on SQL at the list of users i was very shocked to find not just the addition of my login, but also every single other of my users, so now i have 458 additions .
I tried them, and for the ones i know passwords to, this worked perfectly. So all users were recreated somehow when i updated my own user, which must have been why the error for my colleague, as his domain account was not available, but for all other users it worked fine.
I don't think this was using the fact that from a previous detach, the logins were stored in the db and at this point were pushed to the SQL, because the last time i detached would have been automatically during sql 2008 migration. And, a new user i'd created since then, who had not logged in was available to login also, so it had recreated all my users for me.
The only thing that i wanted to test but now can't was what would happen if i had detached the db and reattached, but i wanted to do this when there were no logins in the SQL server, and since luckily they got pushed there i'll have to roll back to a snapshot to see the effects.
LinkBack URL
About LinkBacks
Originally Posted by matt40k 
Need to have that as an optional command on the DBAttach too.
