November 15, 2013 at 6:55 am
GM, here is my dilemma and wanted to pose the question:
SQL Server 2008R2
Compressed backup
NOT compressed database, (wont implement that yet)
backup copied to a diferrent server SQL 2008R2 also.
Original allocation: F: 144 GB, G: 138 GB, H: 140 GB, I: 139 GB, J: 141GB.
Destination allocation F: 87 GB, G: 0, H: 95 GB, I: 104 GB, J: 128 GB, T: 120 GB, U: 130 GB. Z: 100 GB.
Most source allocations are over 138 GB, but I do not have in destination the same size.
When trying to restore, gives error not sufficient space for F:, and so on on the rest of the drives.
How can I restore that backup in more small disk drives, than 5 big chunks of the source.
SQL Server wants "specifically" the same amount of disk as original.
Please help.
Pablo
November 15, 2013 at 6:59 am
A restore recreates the database exactly as it was at the time of backup, including all file sizes. You need the same space for the files as the source database had, no way around this.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 15, 2013 at 7:28 am
You have a total of 702GB on source, 764GB on destination (unless I've missed one somewhere).
The only way to get this restored on the destination is to prepare and plan the files on the source so that they can be moved to the destination drives (use RESTORE DATABASE .... MOVE).
Its a little like a Tetris puzzle for you. 🙂
November 15, 2013 at 9:06 am
You'll have to get a 144+ drives for those files.
If this is for production, you'll need to move the files around correctly. If it's dev/text, I might get a cheaper 1TB drive, do the restore, and then you can move around data in files if you need to in order to fit on other drives.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply