I have an Azure VM - Windows (Windows Server 2008 R2 Datacenter). It has Microsoft SQL Server 2008 R2 running on it (version v10.50.6549).
The Azure VM has backups running according to a policy - and I can see in the backups blade for the VM that they are running nightly.
If I have an issue with the SQL Server, and need to roll back to a prior version of the database, will the File Recovery option from the VM backup be adequate?
Or should I also be running SQL Server backups via a maintenance plan on the server on the VM?
If I have an issue with the SQL Server, and need to roll back to a
prior version of the database, will the File Recovery option from the
VM backup be adequate?
Maybe. VM Backups don't always give you consistent SQL backups. They usually work, but not always. If you have everything setup just right and get consistent VM backups, it might be ok-- but you are running a fairly old OS on that VM, so I'd be nervous. Very nervous. If the data is really important to you, then you should backup the data, not just the VM. Sometimes you want to restore just the data to another VM to investigate, not the entire server. I also hope you have more than just "last night's VM backup" at any given time. Sometimes bad things happen on Friday and you don't notice until Monday.
Or should I also be running SQL backups via a maintenance plan on the
server on the VM?
Yes, you should be running SQL backups if you your data is important. If your data is really important (you don't want to lose half a day of it), you should be doing full backups periodically (e.g. nightly) transaction log backups many times per hour, and keeping a few weeks worth of backups in rotation. If your data is super-important (you don't want to lose more than a few seconds), you should be mirroring it over to another database server in near-time (asynchronously). If it is critical (you don't want to lose any data), then you want to mirror to another server in real-time (synchronously).
Of course, if you are already running in Azure and don't have a DBA, managing a database is a lot easier, safer, more available, and generally cheaper if you use Azure SQL rather than trying to manage your own instance SQL Server in a VM-- oh yeah, and backups are handled for you, with millisecond point-in-time recovery for up to 45 days-- and they handle the mirroring for you to. If you want to mirror to another region across the country, you do have to pay extra for that, though.
Related
We have some machines storing experimental data on Win7 Machines. The experimental software is only compatible with Windows 7 and as such our IT department does not want to connect to this isolated machine anymore. Is there a way to completely "mirror" this Win7 PCs SQL server or completely copy it, and keep it relatively up to date, on a win 10 PC? and by server I mean multiple databases which may grow
in number. Thank you.
Is there a way to completely "mirror" this Win7 PCs SQL server or
completely copy it, and keep it relatively up to date
What you seem to want is LOG SHIPPING. The basic steps are:
Back Up your DB
Restore it on N number of other servers that you want to keep relatively up to date
Configure log shipping, either through he wizard or manually. This will ship the transaction log backups to your other servers
Restore the transaction logs
Of course, this is all automated once you set it up. The relatively up to date is based on how often you do the transaction log backups, how long it takes to travel, and how long it takes to restore. If you only want it updated daily, or weekly, or some other time--you could just copy your DB backups to each of the other servers via PowerShell or what ever method you want, and restore the FullBackup instead of all of the transaction logs. This is a lot simpler, and the only downtime would be during the restore of your secondary servers (how ever long the restore takes).
There are other options which include Database Mirroring and Availability Groups. Each have their own pros and cons, and come at a price.
Does SharePoint 2013 restore only from Database?
I have a scheduled script in MSSQL Server to run all database backups daily , and my SharePoint site also require a daily differential/weekly full backup usually happen in Central Administration. I am aware that multiple backups running would break log chain in this case.
If I stop doing backup in Central Administration and let DB does the backup only, would I be still able to restore my SharePoint site (Contents and Configurations)?
Does SharePoint 2013 restore only from Database?
The short answer is no. A full fidelity SharePoint farm backup is mostly databases but there is also configuration information and data that is stored outside of the databases. The Central Admin backup facility (as well as the Backup-SPFarm powershell commands) initiate SQL backups as well as backups of all the stuff that isn't in SQL. That is the only point-and-click (or type a single command) solution.
Could you get away with only having some of the databases to recreate your environment? Sure but then you'd have to have a documented and tested (and ideally automated) process for recreating the farm from the databases.
We're in the middle of migrating from a windows & SQL 2000 box to a Virtualised Win & SQL 2k8 box
The VMWare box is on a different site, with better hardware, connectivity etc...
The old(current) physical machine is still in constant use -
I've taken a backup of the DB on this machine, which is 21GB
Transfering this to our virtual machine took around 7+ hours - which isn't ideal when we do the "actual" switchover.
My question is -
How should I handle the migration better?
Could i set up our current machine to do log shipping to the VM machine to keep up to date? then, schedule down time out of hours to do the switch over?
Is there a better way?
You take a full backup of the database on sql2k, then restore it with norecovery on sql2k8, then continuously take log backups from sql2k and apply them to sql2k8 (again, with norecovery). So basically you do log shipping from sql2k to sql2k8. When you swithc operation, you onyl take tail of the log backup from sql2k and apply it on sql2k8, this time with recovery, which will bring the database online and run the upgrade from the sql2k format to the sql2k8 format.
SQL 2000 backup restored on SQL 2008 is supported, but you better have SQL 2000 SP4 deployed.
We recently moved from a simple DB recovery model (with daily full database dumps) on our SQL Server 2000 Standard database to full recovery -- combined with weekly full database backups, daily incremental, and transaction dumps every 10 minutes.
Our previous reporting DB instance (SQL Server 2005) was built from the daily backups which no longer exist. I can re-build the reporting database by loading the weekly dump, leaving it in recovery mode, and then restore the incremental backups. Unfortunately, this is not easily scriptable and doing this by hand sucks.
Taking additional full backups of the 2000 production database will ruin the incrementals (which are desirable for a number of reasons).
Is there a better way to do this? We can't do log shipping since we're only SQL Server 2000 Standard (eventually we'll upgrade to 2K5).
Depending on how up-to-date your data needs to be, snapshot replication seems like the best fit for you. It's not that difficult to set up and I believe that it's fairly common in scenarios like yours.
Anyone using MozyPro to backup SQL Server databases?
I'm concerned about the way it does the backup. It just copies data files the way they are. Not using the backup database command.
Is it safe?
MozyPro uses the Volume Shadow Service (VSS) to create backups for SQL Server. SQL Server 2005 has been engineered so that VSS backups are consistent. So this is definitely a valid way to back up SQL Server databases.
Here is a white paper on how the SQL Server 2005 SQL Writer works with VSS.
Microsoft® SQL Server™ 2005 provides
support for creating snapshots from
SQL Server data using Volume Shadow
Copy Service (VSS). This is
accomplished by providing a VSS
compliant writer (the SQL writer) so
that a third-party backup application
can use the VSS framework to back up
database files. This paper describes
the SQL writer component and its role
in the VSS snapshot creation and
restore process for SQL Server
databases. It also captures details on
how to configure and use the SQL
writer to work with backup
applications in the context of the VSS
framework.
Here is the MozyPro manual (PDF), which describes how to restore SQL Server backups that were made using VSS.
That being said, if you don't trust this method, there is nothing stopping you from setting up a backup job and just having Mozy backup your *.bak files.
Judging by the hell I am currently going through with Mozy.. NO NO NO!
The backups work, in theory, just not the restore part. Mozy's extreme incremental backup system results in restores that can take weeks. Apparently. I'm still waiting despite talking their top level tech support, over 10 days have passed.
https://github.com/candera/hobocopy
WHY DOES HOBCOPY USE THE VOLUME SHADOW SERVICE?
Because HoboCopy copies from a VSS snapshot, it is able copy even
files that are in locked by some other program. Further, certain
programs (such as SQL Server 2005) are VSS-aware, and will write their
state to disk in a consistent state before the snapshot is taken,
allowing a sort of "live backup". Files locked by VSS-unaware programs
will still be copied in a "crash consistent" state (i.e. whatever
happens to be on the disk). This is generally a lot better than not
being able to copy the file at all.