SSMS Backup Set list - What is supposed to show here? - sql-server

I use SSMS Maintenance Plan to run 3 backup tasks:
Full backup - each week
Differential backup - each day
Transaction log backup - each 15 minutes
The routine is up and running for the last 3 months.
When I go the my database, in the Restore GUI, I only see one one Full backup and one Differential backup. Is this the expected? Or should I be able to see all the Full, Differential and Transaction backups that exist on my hard disk?

in the Restore GUI, I only see one one Full backup and one
Differential backup. Is this the expected?
This page shows you how to restore to the point you set in "Restore to".
Choose another date and you'll see other backups.
The shortest way to restore your database to today's date is to restore the nearest full backup (2020-11-01) + latest differential (2020-11-06) + some log backups to desired point in time, that's why they are shown up.

Related

Is there a way to keep on restoring SQL database backups periodically, and meanwhile access the database from another application?

I'm periodically getting backups of an SQL database which I would like to restore in my machine. I'm able to do that with RESTORE fullDB WITH NORECOVERY; RESTORE differentialDB WITH RECOVERY;
However, I need to access the restored database in between, as the interval in which I'm getting the backups can be a few hours.
I tried restoring full backup WITH RECOVERY, but in that case I'm getting exception while restoring differential backup.
NB: It's not just one differential backup, it's real time backups taken every few hours. I'm using C# for executing the operations.
Any help is appreciated to solve the issue. Also, let me know if I'm barking at the wrong tree.
Instead of sending SQL database backups from client as .bak files, should I opt any other way to send the data?
Take a look at the STANDBY option for the RESTORE statement. From the docs:
Specifies a standby file that allows the recovery effects to be undone.
NB - differential backups are based on the last full backup taken. So let's say that you take full backups on Sunday, differential backups every other day of the week and you're restoring every day.
Sunday, you'd restore only the full backup, bringing it online for read by specifying STANDBY with the restore
Monday through Saturday, you'd restore the latest differential backup on top of what you've already restored, again using STANDBY
When Sunday rolls around again, you'd need to restore the new full backup.
That said, you mentioned that you're on SQL Express. The database size limit is 10 Gb. At that size, how long does the restore of the full backup take? Is it worth your time? And even there, it's really "how much time are you saving the robot?" because you've already (presumably) automated the restore.

SQL Server 2008: database restore problem with files

We have full backup each Sunday, each evening differential backup and during day transaction log backup.
Now (Tuesday) I want to restore the testing database to state of this afternoon, but I cannot choose full backup, yesterday differential backup and some transaction log from today - see in picture - there is missing the name of files (of full and diff. backup).
But if I choose "to a point in time" option, there are names of full, diff and transaction log backup, but for one (the same time each day) not and restore is not correct.
Please, where is the problem?

Azure Recovery Services and SQL 2014 Managed Backups not playing well together

I started using Managed Backups on my SQL server. It has been working well for over a year. It seems to backup the dbs once a week, and take incrementals every 2 hours.
A month ago, we changed our VM backup solution to Azure Recovery Services. We started running it every night. When Azure Recovery Services runs in the evening, it looks like, from the Windows and SQL logs, it takes a backup of each database before it does a volume shadow copy. They are entered into the logs as TYPE=VIRTUAL_DEVICE: and a big GUID, and a new database lsn number is created. When this VM backup occurs my weekly Managed Backups are invalidated.
When I look in the msdb.dbo.smart_backup_files table where the SQL Managed Backup stores its records to keep track of its backups, I can see there are 2 fields that seem to be important. backup_type. When this equals 1 it is a full backup, and when it is a 2 it is a log. The next field is the backup_database_lsn. This field represents the full backup that the log can be applied to.
When the SQL Managed Backup runs its full backup once a week, a new lsn number is created, and every log file that is created afterwords, has a value in the backup_database_lsn number that points back to that lsn number of the full SQL Managed Backup for that week.
Now, when Azure Recovery Services runs nightly, a new full database lsn number is created from the TYPE=VIRTUAL_DEVICE line in the logs. When I look in the Managed Backup table (msdb.dbo.smart_backup_files) I can see that all then subsequent log files that used to point to the Managed Backup's full lsn number now point to the new lsn number for the VIRTUAL_DEVICE of the Recovery Services backup.
If I need to do a restore of the Managed Backups, I can only get the full backup and 1 days worth of logs. After that, all of the log files now point back to the Recovery Services VIRTUAL_DEVICE backup, which doesn't really exist.
I have looked for the VIRTUAL_DEVICE backup. When I open a database through Enterprise Manager, and click on Restore for a database, it pulls up the most recent full backup (in this case the Recovery Manager full backup), and its log files. If I click on the full backup entry, it believes the file is in the SQL Server backup folder with the name of the file being the GUID. That file does not exist, or it may exist in the night VM backup which I can't view in Azure Recovery Services. Either way, my weekly Managed Backup is invalidated for the rest of the week.
Does anyone know how to make these two work together? I would like to have a full VM backup in case something bad gets installed on the SQL Server and we need to do a full restore, and I'd like to have a weekly full backup with incremental log files in case we need to restore one database.
It sounds as if what you are looking for differential backups. Those would contain everything added to the database following the last full backup.
I.e. you take a full backup on Sunday evening, with a differential backup every day after. On Monday evening, your differential backup would contain everything added since the backup. On Tuesday, it'd contain everything it contained on Monday, as well as everything changed since then.
If you'd do the same using Transaction Log Backups, your Monday evening backup would actually be identical to the differential backup described above. However, the Tuesday version of the Transaction Log backup would only contain the changes from the time of the Monday transaction Log backup.
When it comes to restoring, this would mean that in order to restore to a point in time, you would have to restore the latest Full Backup (Sunday), followed by every transaction log backup since, in sequence (Monday, Tuesday, etc.).
Using Differential backups, though, you would restore the latest Full Backup (Sunday), followed by the latest Differential Backup (Tuesday, if you're restoring on Wednesday).

SQL server 2012 - Difference between point in time and complete?

So i have read Microsoft etc and am struggling to understand the difference in Point in time recovery and complete recovery (i.e. seems to do the same thing, slightly differently).
I.e. when should i use one as opposed to the other, from what i can see i should always use point in time if i have a full backup model?.
Point in time recovery is where you wanted to restore database to specific time of the date, for example some records accidentally deleted at 3:45PM from database and log backup runs every 30 minutes, this is where you can restore database to 3:45PM using Log backups and STOPAT.
RESTORE DATABASE AdventureWorks FROM DISK = 'C:\AdventureWorks.BAK'
WITH NORECOVERY
GO
RESTORE LOG AdventureWorks FROM DISK = 'C:\AdventureWorks.TRN'
WITH RECOVERY,
STOPAT = 'Mar 01, 2017 03:45:00 PM'
GO
Whereby complete recovery is something you can recover database from backups (full/differential) to the last or specific date/time log backup.

How to stagger backups

I have Windows scheduler calling a program that does a full database backup every day at 3:00am.
I would also like to do a transaction log backup every ten minutes.
What is the best way to sync these?
I understand that transaction logs are independent of full back-ups, but is it a problem if the two different tasks both do a backup at 3:00am? i.e. the database is asked to produce a full back-up and a transaction log back-up at exactly the same time.
Perhaps I should have one task and query SQL Server to see if the last full backup was more than 24 hours ago. If not, then do a transaction log backup.
As long as you're running SQL 2005 or higher, you can run log backups at the same time as a full backup without issue. Glossing over a bit of detail, log backups are based on the last completed full backup at the time that the log backup started. The only time it really matters is when you'd need to do a recovery and even then, it's only ever "contentious" (i.e. "which full backup should I restore given that I want to restore to this point in time?") for log backups that are taken while a full backup is in progress.
If ever you need to do a point-in-time restore for such a time, you'd work backwards. That is, first find the log backup that contains said point in time. Then, to find the full backup that it's based on, look at the database backup lsn for that log backup in either msdb.dbo.backupset or by running restore headeronly on the log backup. From there, find the full backup that has that value as the checkpoint lsn. Now, you just need to restore that full backup (using the norecovery option) and every log backup based on it up to and including the log backup you identified in the first step (again, all using norecovery). Then run restore database [yourDB] with recovery to run crash recovery and you're back in business.

Resources