I'm trying to take a copy of a database into another server. I usually been making backup, copy the backup file to another server and restore it. But the backup is 90GB, and the space left after copying the backup to the destination folder is only 26GB. As you probably understand by now I'm not able to restore the database as it doesn't have enough space. So my question is is possible to restore database by replacing backup file? Any other suggestions? Increasing the disc space is not an option as this is just a testing server and the space will be enough after restoring. Thank you
Depending on your SQL Server version have you tried enabling compressing during backup. You would be surprised by how small the backup file can get after compression. Also if your database is set to SIMPLE recovery you could look to reduce the log file size before you backup.
You can find some steps on how to enable compression during backup here
https://sqlbak.com/blog/how-to-configure-backup-compression/
Related
I want to take a full backup of a SQL Server DB, but the concern is the other PC where I want to restore is not having enough disk space. I tried zipping the bak file to reduce the size but, even that doesn't help. Is there a way to take a FULL backup in SQL with minimum storage usage? I know, we can take differential backup but that's not an option as I am restoring the database to the new PC for the very first time. I want to know any configurable setting while taking the backup which might help me in reducing the size of the backup file. Any help is appreciated.
I have to create script which will create the database locally (from database which is on server). Database is 20GB+ and every day is bigger.
What is your advise to do that? I can generate script with all database objects in SSMS, but how operate with data insertion? I mean full script (script which includes data) is not good option. What about one Full Backup and Differetial Backups?
Run generated scripts for all DB objects
Restore Full Backup
Restore Differential Backup
This work is required in order to make possible to test the app locally, on my (another dev's) machine. Thank for every advise!
My advice is to go with a full backup first & get differential backups afterward.
Because a differential backup is not independent and it must be based on the latest full backup of the data. That means there should have a full backup as a base. A differential backup contains only the data that has changed since the differential base. Typically, differential backups are smaller and faster to create than the base of a full backup and also require less disk space to store backup images.
Therefore, using differential backups can save available space and also speed up the process of restoring. At restore time, the full backup is restored first, followed by the most recent differential backup.
I am backing up a SQL Server 2008 R2 database with the intention of restoring it elsewhere. When I back it up using the backup wizard (right click tasks, backup ) the size of the resulting backup is much larger than I know the database should be (c45Gb when there is only about 5Gb of data)
How can I get a reasonably sized backup created to transfer and restore elsewhere?
Thanks,
Dan
Full backups contain all pages in use plus the part of the log that covers the time span that the backup ran for (approximately). It would surprise me if you generated 40GB of log during a backup of 5GB. At this point I'd check if you really backed up the right database. Or, maybe the destination file already contained other backups.
You say:
I created a smaller backup by going to the options tab on the backup
and set the compression to 'compress backup', I also chose Overwrite
all existing backup sets and Backed up to a new media set name.
Apparently, the existing file already contained data. It is unlikely that compression is responsible for the bulk of the savings.
I created a smaller backup by going to the options tab on the backup and set the compression to 'compress backup', I also chose Overwrite all existing backup sets and Backed up to a new media set name.
Given a SQL Server 2008 .bak file, is there a way to restore the data file only from the .bak file, without the transaction log?
The reason I'm asking is that the transaction log file size of this database is huge - exceeding the disc space I have readily available.
I have no interest in the transaction log, and no interest in any uncompleted transactions. Normally I would simply shrink the log to zero, once I've restored the database. But that doesn't help when I have insufficient disc space to create the log in the first place.
What I need is a way to tell SQL Server to restore only the data from the .bak file, not the transaction log. Is there any way to do that?
Note that I have no control over the generation of the .bak file - it's from an external source. Shrinking the transaction log before generating the .bak file is not an option.
The transaction log is an integral part of the backup. You can't tell SQL Server to ignore the transaction log, because there is no way to let's say restore and shrink the transaction log file at the same time. However, you can take a look at DBA post to hack the process, although it is not recommended at all
Alternatively you could try some third party tools for restoring, particularly virtual restoring process that can save a lot of space and time. Check out ApexSQL Restore, RedGate Virtual Restore, Idera Virtual Database.
Disclaimer: I work for ApexSQL as support engineer
No, the transaction log is required.
Option 1:
An option may be to restore it to a machine that you DO have enough space on. Then on the restored copy change the logging to either bulk logged or simple, shrink the logs, do another backup operation on this new copy and then use that to restore to the target machine with the now much smaller transaction log.
Option 2:
Alternatively, perhaps the contact at the external source could shrink the transaction log before sending it to you (this may not work if the log is large due to a lot of big transactions).
Docs on the command to shrink the log file are available here.
This is really a question for the ServerFault or DBA sites, but the short answer is no, you can only restore the full .bak file (leaving aside 'exotic' scenarios such as filegroup or piecemeal restores). You don't say what "huge" means, but disk space is cheap; if adding more really isn't an option then you need to find an alternative way of getting the data from your external source.
This may not work since you have no control over the generation of the .bak file, but if you could convince your source to detach the database and then send you a copy of the .mdf file directly, you could then attach the .mdf and your server would automatically create a new empty transaction log file.
See sp_detach_db and sp_attach_db (or CREATE DATABASE database_name FOR ATTACH depending on your sql server version).
I know this is an old thread now, but i stumbled across it while I was having transactional log corruption issues, here is how I got around it without any data loss (I did have down time though!)
Here is what I did:--
Stop the sql server instance service
make a copy of the affected database .mdf file and .ldf file (if you have an .ndf file, copy that as well!) - Just to be sure, you can always put these back if it doesn't work for you.
restart the service.
Log into sql management studio and change the database mode to simple, then take a full backup.
Change the database type back again and once again take a full backup, then take a transactional log backup.
Detach the database.
Right click on databases and click on restore, select the database name from the drop down list, select the later full database backup created (not the one taken from the simple mode) and also select the transactional log backup.
Click restore and it should put it all back without any corruption in the log files.
This worked for me with no errors and my backups all worked correctly afterwards and there were no more transactional log errors.
I'm using SQL Server 2005.
I need to move a database to a new server with minimum downtime.
Currently my option is to take everything offline, perform a backup, copy the backup to the new server, restore the backup and bring everything back online.
The problem here is that the backup file is about 10Gb, therefore, it takes about 5-10 mins to perform this whole operation.
I've heard of people performing a full backup with everything online and then doing a differential backup so there is less to copy over.
I've taken the full backup, copied that to the new server and restored it. I've then taken a differential backup and copied it to the new server.
The problem is, when I try and restore this backup I get the message "The log or differential backup cannot be restored because no files are ready to rollforward."
I have also tried selecting both the full and differential backup but then I get the error "The volume on device 'D:\FullBackup.bak' is not part of a multiple family media set. BACKUP WITH FORMAT can be used to form a new media set."
Does anyone know what I'm doing wrong and what the easiest way of doing this is?
Thanks
It seems you did not set the NORECOVERY option on the full RESTORE.
You need this option to leave all transactions intact so that you can apply the differential backup later.
If you don't set it, the uncommited transactions get rolled back while restoring the full backup, and the last LSN of the database becomes greater than the first LSN of the differential backup.
Another quick way of doing this is to Detach the database, and then copy the underlying .mdf and .ldf files for your DB straight to the DB, then reattach. Time taken to copy a 10GB file will be much less than the Backup, and it acheives the same thing.