Anybody help me, How to take continuous backup from AZURE portal.(I don't have virtual machine in AZURE) It should be like scheduler running back side and will take back up from sql server in month interval.
SQL Database automatically creates database backups.
If you want it to create backup in month interval, you could upgrade your database service tier to Standard or Premium, SQL Database keeps existing backups until they are 35 days old. It keeps new backups as they occur for 35 days.
For more details, you could refer to this article.
Related
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 am new in SQL Azure and trying to create automatic backup on SQL Azure. But could not found such option for this. I am using free 30 days trial with standard pricing tier. Please help!
These questions can be answered by looking at the documentation. SQL Azure has Point-in-Time restore. For databases in the Basic tier there's Point-in-Time restore for 7 days. For Standard it's 14 days and 35 days for Premium.
All Basic, Standard, and Premium databases are protected by automatic backups. Full backups are taken every week, differential backups every day, and log backups every 5 minutes. The first full backup is scheduled immediately after a database is created.
For long-term backup retention, have a look at Store Azure SQL Database backups for up to 10 years
Edit:
To learn how to configure long-term retention backup, have a look at Manage Azure SQL Database long-term backup retention
I have a SQL database setup on Azure. I was trying to understand if it was automatically backed up or if it is something that I need to setup. Could I get some feedback on this please?
Azure SQL Databases are automatically backed up for you. You don't need to explicitly set anything up. As far as frequency with which the backup happens, from this link:
For local database backups, full database backups happen weekly,
differential database backups happen hourly, and transaction log
backups happen every five minutes. The first full backup is scheduled
immediately after a database is created. It usually completes within
30 minutes, but it can take longer when the database is of a
significant size.
Furthermore, the duration for which the backups are kept (so that go can go back in time and restore them) depends on the service tier of your database. From the same link:
Each SQL Database backup has a retention period that is based on the
service-tier of the database. The retention period for a database in
the:
Basic service tier is seven days.
Standard service tier is 35 days.
Premium service tier is 35 days.
I have inherited a SQL Server 2008 live server with a hot swap-able backup server which has transaction logs shipped every 15 minutes from multiple production servers. One of the production servers keeps getting out of sync, when I came it the last successful log restore on the backup was over a year ago... So clearly my predecessor wasn't watching this, I restored the database and ensured that the logs synced correctly at the next 15 minute interval. However, every couple of days or so (it is random sometimes an hour sometimes 3 days) it gets back out of sync and I have to spend 10 minutes of my morning restoring the database.
Basically I am wondering what I need to be looking at to figure out why these keep getting out of sync? I ran a query I found on sqlauthority.com which shows me the trn's and their license numbers for the primary database and when I try to just restore the transaction logs on the backup database with the file which is supposed to be the next license to get it back in sync it says the license number is too recent, so I try the next file and it says is out of sync and can't be restored.
Any help would be appreciated :)
Upon digging into the job history further I found that my LS_Restore job was succeeding with errors, which were that the sql server agent service account didn't have access to the folder the trn files were stored which it was trying to restore the database from.
I researched what the original developer had setup as the sql server agent service account and then granted that user the necessary permissions, the logs are now restoring as needed.
I hope this information helps someone in the future!!
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.