Is it dangerous to use Sdelete on my exchange server + my sql servers?

Personally, I think you are going to waste your time.

It's not dangerous, (BUT ALWAYS HAVE A BACKUP before any disk maintenance) but I do not think you will see the benefits you are expecting.

What is dangerous is an Exchange Offline Defragment, you may end up with missing mailboxes or corrupt mailboxes, either leave the Online degfragmentation do its work or create a new Mailbox Store on a new virtual disk and MOVE the Mailboxes from one store to the other.

What are you using to backup?

If you were using a CBT (Change Block Tracking) application aware third party backup product e.g. Veeam Backup and Replication of VMware Data Recovery, only block changes are backed up each backup, so Incrementals backups are small, or only the changes in the day are Backed-up.

We have been recently testing V-Locity with good results
http://www.diskeeper.com/business/v-locity/

As for your question, sdelete and defragment, hti the datastore hard, so It would be best completed out of hours, or during quiet periods.

Your right I am using Veeam, it was Veeam directly that reccomended this process.

I have done it on some non critical servers and it seems to help..

Okay, well if Veeam recommend it!

I would be very careful of the Exchange Offline Defrag.

What you can do if you are interested is to check what changes are occuring day by day between backups by following this article

http://jpaul.me/?p=1316

It will give you in "real money" the rate of change or size Incremental in Gigs.

It's very helpful.

Yes they advised me that i move the Paging file to another VHD and then exclude it.

so i did that and another part of their support email states:

Defragment the VM from within the operating system, and then run sdelete on the OS.

You can find sdelete here:
 
http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx
 
Sdelete works by writing zeros to the disk where "deleted" data resides. In order for this tip to have an effect on job speeds, inline deduplication needs to be enabled (inline deduplication will not copy zero MB blocks over the network).

The command you want to run would be:

sdelete -c DIRECTORY
 
where DIRECTORY is a drive letter or a folder that has data removed from it frequently.

After running sdelete you can perform a full backup and track the speed of the backup. Incremental and full backups should benefit greatly from these actions, especially if you have a heavily fragmented disk. If you do not do a full backup after running sdelete you will have an extremely large transfer (we would be tracking the unused "1"s that have been changed to "0"s), but then subsequent backups should be faster.


Obviously they didnt state anything about doing this on an exchange VM in particular so i am twitchy about it!

Ah, okay, the content of the email is a little different.

It's not dangerous, but the effort involved, I do not think will be very rewarding with the benefits.

What sizes are your incrementals?

Use the scripts above to check rate of changes?

Is CBT enabled?

Yes CBT is enabled, i had to use a 4mb block size on my VMFS datastore because the datastore as 1TB in size. I am getting around 83gb every night on an incremental backup...
When we install Vsphere 5 i will make a new datastore and vmotion it there, as i believe vpshere 5 is 1mb block size as standard for any VMFS datasore size.

I will have to use the srcipts mentioned but I just cant work out why its so large every day...