NetApp_Root volume migration procedure

Root volume migration procedure:

1.       vol restrict newroot

2.       vol copy start -S root newroot or ndmpcopy /vol/vol0 /vol/newroot

3.       vol online newroot

4.       vol options newroot root    # aggr options root is from maintenance mode...when done here the aggregate containing newroot will become root since it has the root volume.

5.       vol status   # confirm newroot is "diskroot"

6.       reboot

7.       vol status   # confirm newroot is now root

8.       vol offline root

9.       vol destroy root

10.   vol rename newroot root

### fix cifs shares and nfs exports if needed...

Also, ssl in filerview doesn't usually survive a root vol move...just setup again after reboot
secureadmin disable sssl
secureadmin setup -f ssl
secureadmin enable ssl

NETAPP_STORAGE_SAVING_CONCEPT

NETAPP_STORAGE_SAVING_Concept

Physical & Effective Storage View: The Physical storage view summarizes how storage is allocated while the effective storage view projects the effects of applying NetApp storage efficiency features to usable and RAID capacities. The effective storage view provides an estimate of what it takes to implement the current capacity in a traditional storage environment without any NetApp storage efficiency features. For example, Physical Used Capacity represents the current raw storage used by applications. Effective Used Capacity represents how much traditional storage you would have needed without using Dedupe, FlexClone, and Snapshot technologies.



# ThinProvisioning Savings
## Dedup + FlexClone Savings
### SnapShot Savings
#### RAID-DP Savings
* Areas with no change are marked in grey text


RAID-DP Savings Calculations: Raid-DP savings are based on comparing the cost of deploying a traditional mirroring solution to achieve the similar level of data protection and performance. For example: consider a simple RAID-DP aggregate of 9 disks (7 data disks + 2 RAID-DP disks)



A total of 14 disks are required to provide similar protection in a mirroring implementation.



As illustrated above, deploying RAID-DP results in a savings of 14-9 = 5 disks.


Snapshots Savings Calculations: Snapshots savings are calculated based on the benefits of not having to take frequent full backups. Most customers take a full volume copy every 7 days and incremental backups in between.
Snapshot Savings = (Total Volume Copies x Volume Size) - (physical space consumed by Snapshots)
where Total Volume Copies = 1 + ((# of SnapShots) / (estimate number of incremental backups before a full backup))
Default value for estimate number of incremental backups before a full backup= 7, but can be user adjustable to reflect a different full backup schedule.
For example:
Volume Size = 100 GB
Snapshot Sizes:

• Day 1 - 1 GB
• Day 2 - 3 GB
• Day 3 - 5 GB
• Day 4 - 2 GB
• Day 5 - 4 GB
• Day 6 - 7 GB
• Day 7 - 3 GB
• Day 8 - 6 GB
• Day 9 - 8 GB

Total Snapshot Size for 9 days = 39 GB
Total Volume Copies = 1 + ((# of snapshots) / 7) = 1 + 9/7 = 1 + 1 = 2
Total Snapshot Savings = ((Total Volume Copies) x Volume Size) - Sum of all Snapshot Sizes
= (2 x 100 GB) - 39 GB = 161 GB


Dedupe Saving Calculation: The output from the DF -sh command provides the Dedupe savings calculation. We summarize across all the volumes that have Dedupe enabled. For example:

toaster1> df -sh

Filesystem	used	saved	%saved
/vol/densevol/	37GB	363GB	91%

Used = Used space in the volume
Saved = Saved space in the volume
% savings = saved / (used + saved) * 100
Total Data in the volume = used + saved

FlexClone Saving Calculation: A FlexClone volume is a writable, point-in-time, clone of a parent FlexVol volume. FlexClone volumes share blocks with the parent volume, and only occupy additional storage for changed or added content. FlexClone space saving is computed as apparent space used by FlexClone volumes less actual physical space consumed by those volumes. The shared space between the clone and its parent is not reported in AutoSupport. So FlexClone savings are estimated by comparing aggregate and volume usage.


File and LUN clones are supported starting from Data ONTAP 7.3.1. These savings are rolled up into savings reported by deduplication and are not reported in the FlexClone savings section. FlexClone savings will display "NONE" as a result.

Thin Provisioning Saving Calculation: Thin Provisioning supports efficient pooling of storage for sparsely populated volumes and is enabled on a volume by setting "space-reserve" to none. Thin Provisioning saving is the difference between the apparent space available for each volume and actual space available in the aggregate.


SnapVault Saving Calculation: A single SnapVault secondary system can be a backup target for multiple SnapVault primary systems. Therefore, SnapVault savings are calculated at the SnapVault secondary system level. It is based on the benefits of not having to take frequent full backups on the primary SnapVault servers.

Total SnapVault Savings: = Savings from not having to take full backup on attached SnapVault Primary systems - Sum of all Snapshot overheads
where the formula for calculating SnapVault savings is the same formula used for calculating Snapshot savings.