One of our volumes is currently 16.7TB. This strikes me as rather big and potentially dangerous down the line. I was wondering how we should go about breaking it up to a more manageable size without continually using NDMP
Then you should go with @Ontapforrum suggestion (qtrees).
You could use the same volume, but create qtrees and manually move data to the qtrees. It ou be a migration process as you would do to mode data to another place...
16TB could be big, but compared to the size it could go beyond 100TB and PBs with FlexGroup Vols, it's nothing. So why are you so concerned about the size?
If the concern is regarding the 'backup' (NDMP) then 16TB single volume can be a pain (especially if its taking longer and longer to finish). NDMP in nature can be lengthy process especially if file-history is enabled and volume is packed with millions of small files in a deep directory structure. In such a situation, in order to reduce the NDMP backup time, it is suggestable to break the volume or rather move the dense directories to another volume (under qtrees). Having data distributed in qtrees will ensure the NDMP can use multi-streams for each qtree and also be able to use 'inode-file-map' for full/incremental back instead of examining each file by file.
Then you should go with @Ontapforrum suggestion (qtrees).
You could use the same volume, but create qtrees and manually move data to the qtrees. It ou be a migration process as you would do to mode data to another place...
