PROTIP: New users and disgruntled veterans, try this one small "tweak"

[winnielinnie]

I should have joined BuzzFeed. My clickbait game is strong.


PROTIP: Prepend your pool names with pool, your dataset names with ds, and your volume names with vol.


It will look something like this:

• poolStorage
  
  • dsMultimedia
  • dsDownloads
  • dsArchives
  • dsDocuments
  • dsUserHomes
• poolSSD
  
  • dsScratch
  • dsTemporary
  • volVMDisk1
  • volVMDisk2

This provides a few cost-free benefits.

1. Filtering and browsing snapshots is easier and cleaner. Some words can overlap, in which a keyword, such as "temporary" might exist in a snapshot name and a dataset name. By always prepending with "ds", such as "dsNameOfDataset", you're filtering out exactly this dataset. Therefore, something like the dataset "Temporary" won't get mixed up with unrelated snapshots that also have the word "temporary" in their name. (Typing in "dsTemporary" will exclude unrelated "@temporary-XXXX" snapshots from the results.)
2. You will have a clear moniker to differentiate a pool, dataset, and volume from regular folders and subfolders. (A common misconception with new users.) This makes shares, tasks, and permissions more intuitive.
3. Terminal commands, scripting, and other related work can be more streamlined with the use of consistent prepended abbreviations of "pool", "ds", and "vol".
4. Lessens the likelihood of accidental "collisions" between folder names and dataset names. (As seen in these forums, it's possible for a new dataset to overlay atop a folder of the same name, and the user wonders "Where did all my files go?")

Mods: Please lock this thread before anyone has a chance to reply. I'd rather not read anything to the contrary. I am always correct about everything. I'm not insecure. You're the one who's insecure!

 

[Heracles]

Object naming policies can help a lot. The thing is, they help only as much as they fit the need of the user / operator.

Here, you suggest a policy with a single field and no structure. That may be better than no policy at all but it is possible to achieve much more.

First thing would be to add a structure in your policy. Here, it could be to separate fields with - or _. When using a separator, it is important not to use it inside any field. For that reason, I prefer to use _ or : instead of -.
So your pool would turn to pool_Storage and dataset to ds_Archives.

Another fields can be Dev - Test - Prod, marking resources to use for development, testing before going in prod and production to run services when ready.

With that, retention policies, backups and others can be adjusted.

There are many more (sizing, speed, compression, encryption, ...).

So the policy would be :
field1_field2_field_3_ArbitraryName
and will take care to define fields and the possible values for each one

Again, the policy helps only up to what one will use. If you never encrypt any of your dataset or have everything from the same hardware (so same speed for everything), there is no need to include these elements in your policy.

So sure, define a good policy that fits your needs. It will help you down the road. A simple one like yours is better than none. Also, know that you will rarely hit the perfect naming policy in your first shot. With time, you will find fields and structure that will help you the most so will be able to improve that policy.