0

I have virtual machine with SQL Server. SQL Server files and databases are on the same drive. This drive is way too big and I need to make it smaller to save money. My idea was:

  1. Stop SQL Server.
  2. Create snapshot of the machine.
  3. Create new smaller drive.
  4. Robocopy files (with all attributes, copy, not move) from current drive to new one.
  5. Remove drive letter from old drive.
  6. Assign drive letter to new drive.
  7. Restart SQL Server.
  8. Remove old, big drive when everything seems to be working fine.

I've done similar scenario with non-SQL drive and it worked fine, but I am afraid something unexpected, related to SQL Server, may stand in the way.

Is this a good plan? What can go wrong?

Improve this question
5
  • Theoretically that gameplan should work, as long as all of the database files are all in the same exact folder structure including drive letter (which it sounds like you're remapping the drive letters, so that's good). But isn't one of the benefits of a Virtual Machine is you can easily grow and shrink the drive, I think even as an online operation?
    – J.D.
    Commented Jul 28, 2022 at 12:09
  • 1
    @J.D. Grow drive - no problem. Shrink - not simple, probably due to data fragmentation, maybe other reasons.
    – LukLed
    Commented Jul 28, 2022 at 12:19
  • Interesting. And I assume the drive you're moving away from currently has a bunch of free space on it (at the OS level)? I ask because SQL Server can consume extra space it's not actively using, and that's a common thing people try to shrink as well, but that won't happen automatically just from moving the files to a smaller drive. I assume that's not your case here though.
    – J.D.
    Commented Jul 28, 2022 at 12:26
  • @J.D. I moved 1,5TB database to another machine:) Obviously I need some free space for logs and growth, but not that much:) My provider says shrinking is hard, so I have no other solution. I need to create new drive.
    – LukLed
    Commented Jul 28, 2022 at 13:55
  • 1
    I'd recommend adding a step to verify the databases integrity with DBCC CHECKDB before assuming everything is fine.
    – Ronaldo
    Commented Jul 28, 2022 at 21:10

1 Answer 1

Reset to default
1

It works. I've already done this in production environments.

If it is not a boot partition, it is easier.

Remember to do the CHECKDB after all and guarantee that permissions are equal to the ones on the original disk;

Also, to increase security, before taking the snapshot, put all your databases in READ_ONLY mode. It's important to guarantee that nothing else depends o the disk you will move.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.