Antworten

There are several reasons you might consider partitioning your hard drive:

•Organization: some people feel that splitting data or components across multiple "drives" is a better way to organize their data than creating more folders on a single drive.

•Backup: specifically, backup granularity. It's easier to backup entire partitions separately. Say your operating system is on drive C: and your data is all on drive D:. If you
ever need to reinstall or revert to a backup it's possible, depending on the situation you're recovering from, that only drive C: would need be affected, leaving your data on D: untouched.

•Security: whole-drive encryption is often really "whole partition" encryption. Thus with multiple partitions you could pick and choose which might be encrypted (typically a single
partition containing your sensitive data.

•Speed: Depending on how you use your data, it's possible that moving less-frequently used data to a separate partition "out of the way" of the data you use frequently can have
a speed improvement.

•Multi-boot: if you want to have multiple operating systems installed on your computer that you select at boot time, each must reside in a separate partition. It's also common
to create an additional data partition that they all then use.

For more information, you may also refer to the following third party article:

I'll argue or point out to Arthur that multi-boot isn't really a consideration. 'primary servers' do not get configured for 'multiboot'.

I'm OK with the rest though. 'backup granularity' is somewhat of a nebulous idea, because NOBODY really cares about backup times. RESTORE granularity is MUCH MORE IMPORTANT.

A small OS drive can be restored in a short time. Your data may be 'out of sync' but, at least, the AD is operational. 'you may now sign in and start to work, but I need a while to get your most recent files back' is _possibly_ of great advantage.

There are several reasons you might consider partitioning your hard drive:

•Organization: some people feel that splitting data or components across multiple "drives" is a better way to organize their data than creating more folders on a single drive.

•Backup: specifically, backup granularity. It's easier to backup entire partitions separately. Say your operating system is on drive C: and your data is all on drive D:. If you
ever need to reinstall or revert to a backup it's possible, depending on the situation you're recovering from, that only drive C: would need be affected, leaving your data on D: untouched.

•Security: whole-drive encryption is often really "whole partition" encryption. Thus with multiple partitions you could pick and choose which might be encrypted (typically a single
partition containing your sensitive data.

•Speed: Depending on how you use your data, it's possible that moving less-frequently used data to a separate partition "out of the way" of the data you use frequently can have
a speed improvement.

•Multi-boot: if you want to have multiple operating systems installed on your computer that you select at boot time, each must reside in a separate partition. It's also common
to create an additional data partition that they all then use.

For more information, you may also refer to the following third party article:

I'll argue or point out to Arthur that multi-boot isn't really a consideration. 'primary servers' do not get configured for 'multiboot'.

I'm OK with the rest though. 'backup granularity' is somewhat of a nebulous idea, because NOBODY really cares about backup times. RESTORE granularity is MUCH MORE IMPORTANT.

A small OS drive can be restored in a short time. Your data may be 'out of sync' but, at least, the AD is operational. 'you may now sign in and start to work, but I need a while to get your most recent files back' is _possibly_ of great advantage.

Primarily so that it's easily recognisable 'THAT's my Exchange database partition and I can see it has sufficient room'.

'dedicated' may also not be the best choice of words. I'll happily share that partition with SQL(like) databases. The main thought behind this is that partitions containing such 'database files' are unlikely to benefit from Shadow Copies of the files they
contain. There _are_ circumstances where you may be able to pull such shadow copy and restream the logs to bring the database(s) up-to-date, but it's rare and the constant maintenance of 'ongoing VSS' _probably_ outweighs the rare circumstances where such
may be beneficial. (EDIT) One might consider disabling SC's on such partition.

Keeping such away from your 'general DATA' also means that some gumby user deciding their video/music library belongs on the server doesn't mean that these important databases suddenly get cramped for room. I remember when I didn't have this advice to follow
and someone 'fat fingering' a file copy caused the Exchange to go down. Something easily avoided if _no user_ has access to that partition.

Simplicity: (and convenience?)

Imagine you have to do a FULL Disaster Recovery. I can bring back a minimal OS partition, and the partition holding my Exchange/SQL databases, make the system available. 'You have your most important (or most basic) functions available, restoring 'DATA Files'
is now going to take several more hours'. You're UP, even if some stuff is still missing (which I'm working on).