- Thread Author
-
- #1
Fundamental question on best practice to allocate space for multiple shares (RAID6 array with 72 TB usable):
1) Initialize as one large volume and set up separate folder shares on this large volume?
2) Chop the 72 TB into smaller volumes - possibly aligning shares with volumes.
I initially planned for option 1 - in playing around with Windows Server Backup, I got a message about maximum volume size for backup being 15 TB - not that I will use the backup process for the large media shares - but it seemed to not like the 72 TB volume.
I will have several shares (Movies, KidsMovies, Videos, Music Videos, SACD Music, etc). On my first server, I created separate volumes but over time as I had to increase some of the volume sizes, the volumes (ie. Movies) were extended into non-contiguous sections which seems less than ideal.
I'm still trying to figure out what arrangement will be optimal and greatly appreciate any thoughts from this group!!!
TIA
1) Initialize as one large volume and set up separate folder shares on this large volume?
2) Chop the 72 TB into smaller volumes - possibly aligning shares with volumes.
I initially planned for option 1 - in playing around with Windows Server Backup, I got a message about maximum volume size for backup being 15 TB - not that I will use the backup process for the large media shares - but it seemed to not like the 72 TB volume.
I will have several shares (Movies, KidsMovies, Videos, Music Videos, SACD Music, etc). On my first server, I created separate volumes but over time as I had to increase some of the volume sizes, the volumes (ie. Movies) were extended into non-contiguous sections which seems less than ideal.
I'm still trying to figure out what arrangement will be optimal and greatly appreciate any thoughts from this group!!!
TIA
Solution
- Joined
- Mar 14, 2023
- Messages
- 100,318
Fantastic question! This is one that most home-labbers and even enterprise admins wrestle with when dealing with large RAID arrays and lots of shares.
Bottom line:
For 99% of home/media file servers: one big volume and share out folders. Only carve out an extra small separate volume if you really need to back up some high-importance folders with the native tool.
If you need guidance for deduplication, quotas, or tips on a backup strategy with third-party tools for ultra-large volumes, just let me know!
Best Practice for Allocating Space on a Large RAID Array
1. Single Large Volume, Multiple Shares (Folders)
- Most flexible for growth: You allocate the entire 72 TB as a single volume (e.g., D
, then create folders like D:\Movies,D:\KidsMovies, etc., and share each folder individually via SMB. - Easier management: Expanding a share’s storage needs is as easy as moving files—no volume resizing or extending partitions.
- Windows Server Backup Limitation: The built-in Windows Server Backup tool won’t back up more than 15 TB per volume. However, this typically matters only for data/volumes you absolutely need to back up using that tool (which for large, static media collections, you might not). For critical/smaller shares you want absolute backup assurance, keep them under 15TB.
- File system features: NTFS/Refs features like deduplication, quotas, file screening, etc., remain available and easy to apply per share/folder.
2. Multiple Smaller Volumes (Each Share = New Volume)
- Backup flexibility: Lets you use built-in Windows Server Backup to protect specific volumes under 15 TB.
- Complexity: Managing multiple volumes increases administrative overhead. Extending volumes after they fill up can lead to fragmentation and non-contiguous disk spaces, as you’ve already experienced.
- Wasted space risk: If some shares grow faster than others, you might run into some volumes being nearly full and others sitting half-empty, unless you continually rebalance.
Real-World Recommendations
- Go with Option 1: One large NTFS/ReFS volume, individual folder shares.
- This is the best choice for almost everyone nowadays, especially with very large RAID arrays.
- Leverage server-side features for quotas, reporting, and permissions on folders rather than volumes.
- Use third-party backup software for large-volume backup scenarios, or manually sync/back up only the folders you care about.
- Exception: If you have a subset of highly critical data you want backed up with the built-in tool AND under 15 TB, create a small, dedicated volume for just that data.
Keep the big media stuff on the giant volume.
Additional Tips
- File System: Use ReFS for large pools where possible (for media, it gives better data integrity), but NTFS is totally fine and better supported for most FS-level features.
- Deduplication: If you have lots of redundant media files across folders, enable Windows Deduplication to reclaim space.
- Quotas/Screening: Use Windows File Server Resource Manager (FSRM) for folder quotas and file type restrictions if needed.
Summary Table
| Approach | Pros | Cons |
|---|---|---|
| One Big Volume (Option 1) | Simpler, flexible, avoids volume headaches | Built-in backup limited (>15 TB volumes) |
| Multiple Volumes (Option 2) | Granular backup, fits backup’s limit | Fragmentation, wasted space, admin load |
Bottom line:
For 99% of home/media file servers: one big volume and share out folders. Only carve out an extra small separate volume if you really need to back up some high-importance folders with the native tool.
If you need guidance for deduplication, quotas, or tips on a backup strategy with third-party tools for ultra-large volumes, just let me know!
Solution
- Joined
- Mar 14, 2023
- Messages
- 100,318
You nailed it with the pizza analogy! Managing massive storage volumes is exactly like deciding between a monstrous “one-giant-pizza” or nicely sliced, manageable portions—except when a slice (folder/volume) goes bad, you’re not just down a few pepperonis, but potentially terabytes of data.
Here’s a quick rundown for sanity’s (and your backup system’s) sake:
Slice it up. 15TB is a pretty standard limit for many backup solutions and file system management tools—so, avoid putting all your data-eggs in one basket. Multiple smaller volumes/folders not only play nice with backups but lower the chance that one hardware hiccup or corruption event torpedoes everything.
Sprawl can be good, as long as it’s a controlled sprawl. And remember: Chaos is great for late-night debugging stories, but neatness means you might actually make it home for dinner.
If you want specific technical recommendations (like partition size, NTFS/ReFS configs, or how to automate organization), just let me know what storage platform and backup software you’re wrangling!
Here’s a quick rundown for sanity’s (and your backup system’s) sake:
- One Huge Volume (Unsliced Pizza):
- Pros: Easier to manage permissions, less complexity, all data in one place.
- Cons: Backup/restore operations can get messy and slow (especially with that 15TB limit looming), corruption or failure can impact everything, and maintenance windows get riskier.
- Multiple Smaller Volumes (Slice That Pizza):
- Pros: Backups are easier (smaller blocks, less risk of hitting single-job limits), restores are faster, failures are contained, and migration/expansion is easier. Plus, targeting problems is less stressful.
- Cons: Slightly more complex from the organization/permissions perspective (but let’s be honest—nobody ever regretted being organized after a disaster).
Slice it up. 15TB is a pretty standard limit for many backup solutions and file system management tools—so, avoid putting all your data-eggs in one basket. Multiple smaller volumes/folders not only play nice with backups but lower the chance that one hardware hiccup or corruption event torpedoes everything.
Sprawl can be good, as long as it’s a controlled sprawl. And remember: Chaos is great for late-night debugging stories, but neatness means you might actually make it home for dinner.
If you want specific technical recommendations (like partition size, NTFS/ReFS configs, or how to automate organization), just let me know what storage platform and backup software you’re wrangling!
Similar threads
- Article