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.
Related
I want to migrate my SQL Server Databases to AWS EC2 instances or AWS RDS using DMS Service of AWS?
How can I do that? What will be the architecture for the same? How to secure Databases in AWS?
What is the difference between both approaches? Can anyone provide architecture for both the approaches?
We're in the middle of moving our on-prem SQL Servers to AWS EC2 right now. For us, we're adding replicas to existing Availability Groups. When the time comes, we'll fail over the AG and tada! we'll be in AWS. But even if we didn't have AGs, I'd still do this with backup/restore over DMS. From the little bit that I looked at DMS, you need either CDC or a rowversion column on every table you want DMS to work with. Which seemed like a lot to me.
In case you're not acquainted with moving a database with backup/restore, here's the bones of it.
Copy a full backup to the target system
Restore that backup, being sure to specify with norecovery to allow it to accept more backups
Copy/restore a differential backup, again specifying with norecovery
Copy/restore transaction log backups. You'll keep doing this on a periodic basis until you're ready to do your cut over.
When you're finally ready to turn off the source database, take a log backup of the source, specifying with norecovery. This will create what is called a tail of the log backup and will stop anything from being able to write to the source database. Copy/restore that last log backup over and you're migrated.
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.
I have a server which is running SQL Server 2008R2 SP1 and there are more than 200 online databases with their specific login and I want to move all of these databases to another machine with the same software SQL Server 2008R2 SP1.
I can afford downtime up to 8 hours so I'm not looking for complex solution like database mirroring and logshipping.
I have tried Backup & Restore, it work fine but trouble me in two ways :
1- I couldn't transfer login to new server so all of my users will have to create their user again which will my users to get angry.
(I have tried to script all of the logins from the security section but since I have realize the hash algorithm between two system maybe different, I cannot transfer my logins in this way)
2 - I have to backup & restore each database one by one which is so time consuming.
I have also tried copy wizard, but I have encountered with following error message at the final stage :
"SQL Server schedule job" job failed the job was invoked by user sa step to run was step 1.
Since mysource server is running based on windows server 2003, I cannot use the powershell V3 solution.
I have done many searches but all I found was a solution to transfer one database to another server.
But since I'm looking for a solution to transfer mass databases, this situation is being hair pulling and so difficult So I wil be very appreciated if you can provide me an easy and practical solution.
for moving logins between servers
https://support.microsoft.com/en-us/kb/918992
[moving logins][1]
then backup and restore all databases in that migraton day using pre built restore script if the db size is small , later restore the differential backups and make it online. if the size is an issue then implement log shipping or mirroring
I manage a web application for a client with the following specs:
ASP.net 3.5 running on a Virtual Windows 2003 Web Server
SQL Server Standard hosting the database
Database current size of 6Gb, with 1Gb/month growth rate
One single table is responsible for 98% of the size, holds the most critical data for the client
Log is not kept for this big table, only selects are done in this table
50 Gb FTP space avaiable for backup
Considering this scenario, what would be the best strategy for a SQL Backup and what tool would be best suited for this task (commercial applications included, client can pay for the license fee)?
Here is the strategy we use for CodePlex.com:
All SQL servers run with a peer server using SQL mirroring
Weekly full backup (stored on separate drive from databases)
Daily differential backup (stored on separate drive from databases)
Transaction log backup every 5 minutes (stored on separate drive from databases)
Daily tape backup
Tape backups taken offsite weekly
Also very important test your backups! Studies have shown that over 30% of untested backup procedures are flawed. Here is our backup testing strategy:
Every 30 minutes verify the full backup file exists (using scheduled task)
Every 30 minutes verify the differential backup file exists (using scheduled task)
Every 30 minutes verify the transaction log backup file exists (using scheduled task)
Every 30 minutes verify the database mirroring is configured (using scheduled task)
Every day, do a test restore of the full+differential backup and report the table row counts (using scheduled task)
Once a month do a test restore of the most recent tape backup and verify the data
It depends how critical is the data. Here is however how I i'd do it.
1. Run a full backup every day.
2. Run a differential backup every 4 hours.
3. Run a transactional log backup every 15 minutes
4. Keep a copy at the site and move a copy off the site as well as soon as the backup is done.
The database is not too big, and this is easily doable.
Use a third party tool like Redgate SQL Backup and it will automatically compress and encrypt the database backup for you. I have used it extensively and am a big fan.
Additionally if you another site available, and the data is very critical, you might want to think about setting up log shipping as well.
This is a VPC? Can you install apps?
http://www.jungledisk.com/
That's what we use - make a sql job that pushes out a backup every day, then use that service to push a copy back to Amazons S3 service. If not maybe you could have a local app that pulls the backup to a machine then pushes it /w S3 webservice, or still using Jungledisk.
This is important! If your app goes down it hurts! Also make sure you backup your deployed app and resources stored there... i.e. uploaded content to your apps storage directory.
I was supposed to type in my answer to your question but I realized there are lots of far greater resources somewhere like this article in SQLServerCentral.com. You can also find lots of "Best Practices on Backup" like this one.
You might also want to take into consideration how much data you can afford to lose and how long it will take you to restore the database. Your client may decide that they never want to lose more than 15 minutes of data ever, or they may decide that losing up to a days worth of data is okay with them.
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.