I am trying to figure out how SQL Server DBAs are doing their backups and verify in 2005. I use the Idera's free stored procs (which is no longer available to download btw) to backup and verify and have gotten around 65% compression. If there any other free alternative?
Not sure if this is what Idera's scripts do, but you could script a (native) SQL backup to a temporary location, then call PKZip or 7zip or some command-line compression software to compress the backup to a permanent storage location.
Note that most of these zip utilities have a high CPU cost.
See the discussion in the comments of this post:
https://blog.stackoverflow.com/2009/02/our-backup-strategy-inexpensive-nas/
(Edit: Or just upgrade to SQL2008 R2, which supports native backup compression.)
The Idera which you are using an 3rd party tool , with that tool it can be backup/restore & you can monitor for your server & databases..
As you asked the question-
am trying to figure out how SQL Server DBAs are doing their backups and verify in 2005. I use the Idera's free stored procs (which is no longer available to download btw) to backup and verify and have gotten around 65% compression. If there any other free alternative?
SQL server has it's own native tool where you can set up your backup of databases to go disk,
usually with the SSIS packages by using Maitenace plan (or)T-sql(where you can configure Full,differntial and log backup also)(where after backup finish you can check the verify integrity of the backup) but if the database grows more and more then you may need to ensre about the capcity as this goes to disk(here you need cut the backup stragegy for big database say 1TB bcz usually for Big database taking full daily causes lot of I/O then you have to decide weekly full backup along with the other days differntial backup in place) & you should do the cleanup also for howmany days you want(in the same maintenace plan only it exists).
see for ex-http://bradmcgehee.com/2010/01/13/how-to-use-sql-backup-inside-a-maintenance-plan/
but the backup/restore totally depends on how well you manage from your side by knowing the business risk & communincated with them.
In sql server 2008 onwards you have backup compression like how the Idera sql safe does.
But the Backup usually depends on what they have Implemented whether from the Native tool or from any other 3rd part like Commvault,Idera,TDP(goes to tape) etc... it depeds on what is agreed for.
Backup-
http://msdn.microsoft.com/en-us/library/ms186865.aspx
Free (good) SQL Server DBA tools are hard to find. = /
Have you considered Windows Backups?
It's definitely not the best thing out there, and it takes up a lot of space, but it is free, it does backup your data, and you already have it installed.
Related
I have a database of 1.10gb size in Microsoft SQL Server 2005 and when I zipped this database, the file that contains this database will produce the size only 80 Mb.
what is the reason for reduce this large amount size?
if there any mistake in data allocation in that database that is, static allocation
There was no any free technique available for SQL server 2005 backup compression, database administrator could do it by using 3rd party tools.
See this blog: http://sqlblogcasts.com/blogs/davidwimbush/archive/2009/09/24/backup-compression-on-sql-2005.aspx
& 3rd party tool – SQL safe lite, you can find related information # http://www.idera.com/Products/SQL-toolbox/SQL-safe-lite/
I have not used this software so try it on your own risk.
Also this: http://www.loudsteve.com/2009/01/21/hack-together-backup-compression-in-sql-2005/
Please note that you must Shrink DB before backup and free unused allocated space.
I'm looking at backup routine which allows our production database to be backed up with sensitive data stripped out of certain columns within the database to be exported to our testing server.
The routine should require the least human intervention and hopefully just be a simple customisable SQL script without taking the production database offline.
Database server is SQL Server 2008.
I've run into similar requirements before, and the only sure solution I know of is to use a copy of your production database. You can mask/delete data on the copy and run backups from there. Yes it's ugly and a waste of resources, but to date I haven't found a solid alternative for this particular problem.
As for the copy method, you do have some options:
Replication
Scheduled DB copy
Backup/restore from production
So while I admit this solution is pretty cringe-worthy, it can be automated and serve your purposes. If you can find productive uses for the database copy that don't require your deleted information (e.g. reports, testing, development) then this can actually be a less-than-terrible solution. It can be a nice security boon to have a slightly out-of-date version of your production database with sensitive data removed.
If you want to take a backup then Just type
BACKUP DATABASE Dbname
If you want to specify offline or anything else then you can do it.
The backup file will generate on the default path of the SQL SERVER 2008.
Whenever I move a SQL Server database to a new server I always to a database backup and restore. I have seen a lot of people, especially DBA's who will to a detach / re-attach of the MDF file instead. What is the preferred method and why? I find a backup/restore to be safer, less likely hood of corruption.
I just did this. For our small databases, I did a backup/restore - just because I felt like it was 'safer'. However, when moving LARGE databases, it is so much faster to just detach, copy and attach. This beats having to do a (usually slow) backup, followed by a copy and a (usually slow) restore.
Microsoft recommends using alter database 'planned relocation procedure'.
Note, you can use attach/detach to upgrade between SQL versions as shown in the link.
I have two databases: the source is a database from SQL Server Express by client and the target is a database from SQL Server 2005 database as backup initially. What I need is to sync the source to the target db if there is any difference between them and the sync is one-way from source to target.
I am not sure what tools are available. I tried to google this issue and found MS VS Team Edition (2005) has a tool to sync database, which can generate T-SQL scripts as well. Not sure if this one is good or not. Can I use the script as a scheduled job on SQL Server (target server)? By the way, I don't have Team Edition right now but I do have VS 2005 Prof. Any suggestions?
IMHO by far the easiest and fastest way to sync the two databases one-way (A to B) is to backup database on A and restore it on B. This could be done via T-SQL, let me know if you would like me to post SQL statements
Ideally you would set up Transactional Replication from your source to your target(s). However, since your source is Express edition and Replication does not work with Express as a publisher (source) but only as a subscriber (target), you cannot use it.
The best solution would be to upgrade your Express edition to SKU that supports Replication publishing (ie. Standard Edition).
Log shipping, or manual backup/restore, will not work because it will create an absolutely identical copy of the source db at the target, overwritting any changes made by the target (you mention 'some differences' may exist). Same goes for File/Copy.
SQL Compare tools are OK for a one time manual operation, but they fail at automated operations because they always compare the two databases from scratch, ei. are not capable of synching just what changed. As soon as data grows to a sufficient size, the comparison approach is doomed as it has to ship over the entire database for purpose of comparison alone.
Other solutions are to set up pro-active real-time ETL, but the time/cost investment into this is prohibitive compared with the cost of a SE license and deploying Replication.
Pay to play:
http://www.red-gate.com/products/SQL_Compare/index.htm
Free, open source:
http://www.codeplex.com/OpenDBiff
You should into the SQL Server tools produced by Red-Gate. I've found them to be the best around.
If you have SQL Server 05, you can use replication services(this comes with SQL Server). If you open up your management studio, under your server folders you should see one titled "Replication". From here you can setup subscriptions or publications with push or pull syncs.
Here's MSDN's take: http://msdn.microsoft.com/en-us/library/ms151198.aspx
If this is a one time / once-in-a-while thing, you can use SnapShot Replication.
If you need the databases to be in sync all the time, you can use Transactional Replication.
http://msdn.microsoft.com/en-us/library/ms151847.aspx
In addition to Red Gate tools you can try DB Ghost as well http://www.innovartis.co.uk/. It's most useful as a automated build tool, but does also have an user interface to diff and sync databases. It costs ~$350.00
USing microsoft sync framerok
http://msdn.microsoft.com/en-us/library/ee819079.aspx
http://msdn.microsoft.com/en-us/library/ff928525.aspx
I would like to save my backups from my SQL 2008 server to another server location.
We have 2 servers:
Deployment server
File Server
The problem is that the deployment server doesn't have much space. And we keep 10 days backups of our databases. Therefore we need to store our backups on an external "file server". The problem is that SQL doesn't permit this.
I've tried to run the SQL 2008 service with an account that has admin rights on both pc's (domain account), but this still doesn't work.
Any thoughts on this one.
Otherwise we'll have to put an external harddisk on a rack server and that's kinda silly no?
EDIT:
I've found a way to make it work.
You have to share the folder on the server. Then grant the Development Server (the PC itself) write permissions. This will make external backups possible with SQL server.
Don't know if it's safe though, I find it kinda strange to give a computer rights on a folder.
You can use 3rd party tools like SqlBackupAndFTP
There are several ways of doing this already described, but this one is based on my open source project, SQL Server Compressed Backup. It is a command line tool for backing up SQL Server databases, and it can write to anywhere the NT User running it can write to. Just schedule it in Scheduled Tasks running with a user with appropriate permissions.
An example of backing up to a share on another server would be:
msbp.exe backup "db(database=model)" "gzip" "local(path=\\server\share\path\model.full.bak.gz)"
All the BACKUP command options that make sense for backing up to files are available: log, differential, copy_only, checksum, and more (tape drive options are not available for instance).
you might use a scheduler to move backups after a certain amount of time after the backup started with a batch file.
If I remember correctly there's a hack to enable the sql server to back up on remote storage, but I don't think a hack is the way to go.
Surely the best possibility may be to use an external backup tool which supports the use of agents. They control when the backup starts and take care of the files to move around.
Sascha
You could create a nice and tidy little SQL Server Integration Services (SSIS) package to both carry out the backup and then move the data to your alternative file store.
Interestingly enough, the maintenance plans within SQL Server actually use SSIS components. These same components are available to use within the Business Intelligence Design Studio (BIDS).
I hope this is clear but let me know if you require further assistance.
Cheers, John
My experiences older versions of MSSQL, so there may be things in SQL2008 which help you better.
We are very tight on disk space on some of our old servers. These are machines at our ISP and their restore-from-tape lead time is not good - 24 hours is not uncommon :( so we need to keep a decent online backup history.
We take full backup on Sunday, differential backup each other night, and TLog backups every 10 minutes.
We force Tlog backups every minute during table/index defrag and statistics update - this is because these are the most TLog-intensive tasks that we run, and they were previously responsibly for determining the size of the standing Tlog file; since this change we've been able to run the TLog standing size about 60% smaller than before.
Worth watching the size of Diff backups though - if it turns out that by the Wednesday backup your DIFF backup is getting close to the size of the Full backup you might as well run a Full backup twice a week and have smaller Diff backups for the next day or two.
When you delete your Full or Diff backup files (to recover the disk space) make sure you delete the TLog backups that are earlier. But consider your recovery path - would you like to be able to restore last Sunday's Full backup and all Tlogs since, or are you happy that for moment-in-time restore you can only go back as far as last night's DIFF backup? (i.e. to go back further you can only restore to FULL / DIFF backup, and not to point-in-time) If the later you can delete all earlier Tlog backups as soon as you have made the DIFF backup.
(Obviously, regardless of that, you need to get the backups on to tape etc. and to your copy-server, you just don't have to be dependant on tape recovery to make your Restore, but you are losing granularity of restore with time)
We may recover the last Full (or the Last Full plus Monday's DIFF) to a "temporary database" to check out something, and then drop that DB, but if we really REALLY had to restore to "last Monday 15-minutes-past-10 AM" we would live with having to get backups back from tape or off the copy-server.
All our backup files are in an NTFS directory with Compress set. (You can probably make compressed backups direct from SQL2008??, the servers we have which are disk-starved are running SQL2000). I have read that this is frowned upon, but never seen good reasoning why, and we've never had a problem with it - touch wood!
Some third-party backup software allows setting specific user permissions for network locations. So it doesn't matter what perrmissions SQL Server service account has. I would recommend you to try EMS SQL Backup, which also supports backup compression 'on fly' to save storage space.