The SQL is backup my database into many .trn files (in backup folder).
The problem is Azure Data Studio can't restore the database from .trn files. It only works with .bak file.
Is there a way to convert .trn to .bak (single file)?
You need a database backup file (typically bak extension) to go with a transaction log backup file (typically trn extension). A transaction log backup alone cannot be restored.
You can read as much in the documentation on transaction log backups:
Minimally, you must have created at least one full backup before you can create any log backups. After that, the transaction log can be backed up at any time unless the log is already being backed up.
And from Restore a Transaction Log Backup
Backups must be restored in the order in which they were created. Before you can restore a particular transaction log backup, you must first restore the following previous backups without rolling back uncommitted transactions, that is WITH NORECOVERY:
The full database backup and the last differential backup, if any, taken before the particular transaction log backup. Before the most recent full or differential database backup was created, the database must have been using the full recovery model or bulk-logged recovery model.
All transaction log backups taken after the full database backup or the differential backup (if you restore one) and before the particular transaction log backup. Log backups must be applied in the sequence in which they were created, without any gaps in the log chain.
If what you have is a database backup file and several transaction log backup files, and you really need just one backup file, you would have to restore it in a location that can accept the transaction log backup files (e.g. locally, or on your programming environment). Then from the restored database, take a database backup which you can then use as a single backup file.
Related
In SQL Server Management Studio I can take database backups and save them as .bak files, which can also be restored in SQL Server Management Studio.
Is there any difference between doing this and setting up a script which backs up the .MDF and .LDF files - and if there was ever an issue, I could just re-attach the .MDF and .LDF files?
Thanks
It depends on your restore needs and backup space. It's certainly possible to to just reattach MDF and LDF files, but there are some limitations:
You have to detach the database first, make the backup (both files at the same time) and then reattach. This means downtime.
You cannot make incremental backups.
You cannot make differential backups.
You cannot do point-in-time restoration.
You basically have to make a full backup each time you copy the MDF and LDF files, which can really eat up space (thus, it can be better to do incremental or differential backups).
SQL Server has built-in mechanisms that can run without invoking external scripts to do regular backups. MDF and LDF backups require external scripts that have permission to access the data directory, the backup location and the server to attach/detach the database.
Basically, I'd say that unless you have a really good reason to not use the built-in backup functionality, I'd avoid doing manual backups of the MDF and LDF files.
Database backups are much more powerful than backing up the files.
First of all, if you backup the files while the database is in use, because it is changing constantly you may get something that works, or more likely you will get a corrupted file. A proper database backup coordinates ongoing changes with the backup process so that the backup file is perfectly consistent. A file backup may give you a file that has half of the changes in a transaction and not the other half, or,worse, half the changes in a particular page and not the other half.
Secondly, proper database backups let you recover the database to ANY point in time beginning at the oldest full backup, not just the point in time that the backup was made. (You will need the chain of all log backups made since the full backup to do this).
EDIT: note that as pointed out in the comments, the built-in functions don't necessarily provide point-in-time recovery--only if you use the type of backups that provide that functionality (though there are other reasons to use that type of backup even if you don't need point-in-time recovery).
The files generated by SQL Server backup only contains data not free, unused, space. The .mdf and .ndf files will contain (sometimes very large amounts of) empty, unused, space making these files larger than the backup files. And you have to detach the database from SQL Server to copy it out.
When I restore an SQL server database from backup, I usually do it from a .bak file on the disk. There is also an option to restore from Database as a source - see this picture
Is this backup restored from the database log file?
It's from existing backups from databases that have been created on the server. It's essentially a list of all databases that have at least one recorded backup in the msdb database.
Source: MSDN
Select the database to restore from the drop-down list. The list contains only databases that have been backed up according to the msdb backup history.
during the setup of the mirroring database in sql server 2012, i accidentally made 2 backup of the original database.
after restoring the database on the mirror server, the databases were not synchronized.
to solve the issue, i changed the recovery model from 'full' to 'simple' and back to 'full' again. and then backed up the database again. when restoring it on the mirror server the mirroring procedure.
my question is why does the synchronization fail if i take more than one full backup of the original database?
It's because of the log chain, mirroring is kind of like restoring transaction log backups to the other server but automatically, for it to work, you need an unbroken log chain from a full backup to the last t-log backup, so the log chain will look like this (with nice sequential LSNs):
Full-1->LogA->LogB->LogC->Full-2->LogD->LogE->LogF etc...
So in the example above, if you restored the Full-1 backup, you can restore log backups A,B,C but not D,E,F. You can only restore those if you restore Full-2.
In mirroring, you take a Full backup of the DB and then restore it, SQL server then looks at the Log Sequence Numbers (LSNs) and transfers transactions that aren't present in the restored mirror database, if you take another full backup, you break the chain of sequential LSNs.
In your case, it's like you restored Full-1 and then tried to apply Logs D,E,F to it, there is a gap in the sequence numbers. It should have worked for you if you had just re-restored the second accidental backup that you took to the mirror server and then started mirroring. By changing the recovery model, you completely reset the log chain and have to start again.
I just started at a new company and I'm responsible for the reporting sql server. Their process to keep the reporting db in sync with the production db is to constantly keep the production db in Standby/Read-Only mode so that they can apply a transaction log that comes each night from the production db.
What I need is to grab a copy of the current reporting db so that I can put it on a test server, unfortunately I can't take a full backup of it in the standby/read-only state.
I realize that I can get it out of that mode by doing "restore database 'dbname' with recovery". However after I do that, can I get the db back into the Standby/Read-Only mode to continue applying the nightly transaction log?
No. You can't return a database to Standby/Read-Only mode after using the restore WITH RECOVERY option.
When a database is in recovery mode, there may be incomplete transactions in the database, which means the database is not in a ready state. Either, you restore the next transaction log backup, which will complete the transactions, or you do the restore 'WITH RECOVERY', which will roll-back open transactions. Once, the open transactions are rolled-back, the next transaction-log backup can't be restored, because the database is no longer in a state expected for the transaction-log restore.
EDIT:
An alternative is to restore a copy of the most recent production full backup and restore the appropriate transaction-log backups to that database.
I wanted to reduce the size of my log file in SQL SERVER 2005, which grown to 16 gigs, so I created a backup and used the dbcc shrinkfile command to shrink it. All that is set. Now what should I do with the backup file that is created - should I delete it? What impact will deletion have?
Deleting the file will mean you will not be able to do point-in-time restoration - you will only be able to restore to the last database backup you made.
If point-in-time restores are unimportant to you, you can safely delete the backup - otherwise store it somewhere safe (like a tape, or other removable storage).
If you're not using anything that requires a transaction log (e.g. database mirroring) you could also consider switching the database into "simple recovery mode" which avoids transaction log use anyway.