ONTAP Hardware
ONTAP Hardware
Hello All!
We have FAS3140, Data ONTAP Version 7.3.4. We need to move the root volume to another shelf. The volume is alone on an aggregate of three disks. The system is not in production. Could you give a link or a straight instruction how to do this?
Thank you if you answer.
Hi,
1. Create a New Volume "Eg: volrootnew"
2. Turn NDPMD Online - ndmpd on
3. Use NDMPCOPY to Copy the Root Volume to the new Volume.
a. myhost>ndmpcopy /vol/vol0/source_path /vol/vol0/destination_path
4. Once its done, you have select the new Volume to be the Root Volume
I have done a demo for you, on my FAS2040 Demo Box. Have attached the File.
Please let me know if you face any issues.
GGDEMO > priv set diag
GGDEMO*> ndmpd on
GGDEMO*> ndmpcopy /vol/vol0 /vol/volrootnew
Ndmpcopy: Starting copy [ 1 ] ...
Ndmpcopy: GGDEMO: Notify: Connection established
Ndmpcopy: GGDEMO: Notify: Connection established
Ndmpcopy: GGDEMO: Connect: Authentication successful
Ndmpcopy: GGDEMO: Connect: Authentication successful
Ndmpcopy: GGDEMO: Log: DUMP: creating "/vol/vol0/../snapshot_for_backup.103" snapshot.
Ndmpcopy: GGDEMO: Log: DUMP: Using Full Volume Dump
Ndmpcopy: GGDEMO: Log: DUMP: Date of this level 0 dump: Wed Apr 20 12:10:49 2011.
Ndmpcopy: GGDEMO: Log: DUMP: Date of last level 0 dump: the epoch.
Ndmpcopy: GGDEMO: Log: DUMP: Dumping /vol/vol0 to NDMP connection
Ndmpcopy: GGDEMO: Log: DUMP: mapping (Pass I)[regular files]
Ndmpcopy: GGDEMO: Log: DUMP: mapping (Pass II)[directories]
Ndmpcopy: GGDEMO: Log: DUMP: estimated 1073209 KB.
Ndmpcopy: GGDEMO: Log: DUMP: dumping (Pass III) [directories]
Ndmpcopy: GGDEMO: Log: RESTORE: Wed Apr 20 12:11:00 2011: Begin level 0 restore
Ndmpcopy: GGDEMO: Log: RESTORE: Wed Apr 20 12:11:00 2011: Reading directories from the backup
Ndmpcopy: GGDEMO: Log: DUMP: dumping (Pass IV) [regular files]
Ndmpcopy: GGDEMO: Log: RESTORE: Wed Apr 20 12:11:03 2011: Creating files and directories.
Ndmpcopy: GGDEMO: Log: RESTORE: Wed Apr 20 12:11:09 2011: Writing data to files.
Ndmpcopy: GGDEMO: Log: DUMP: dumping (Pass V) [ACLs]
Ndmpcopy: GGDEMO: Log: DUMP: 1073704 KB
Ndmpcopy: GGDEMO: Log: RESTORE: RESTORE IS DONE
Ndmpcopy: GGDEMO: Log: RESTORE: The destination path is /vol/volrootnew/
Ndmpcopy: GGDEMO: Log: DUMP: DUMP IS DONE
Ndmpcopy: GGDEMO: Log: DUMP: Deleting "/vol/vol0/../snapshot_for_backup.103" snapshot.
Ndmpcopy: GGDEMO: Notify: restore successful
Ndmpcopy: GGDEMO: Notify: dump successful
Ndmpcopy: Transfer successful [ 1 minutes 27 seconds ]
Ndmpcopy: Done
GGDEMO*>
GGDEMO*> vol options volrootnew
nosnap=off, nosnapdir=off, minra=off, no_atime_update=off, nvfail=off,
ignore_inconsistent=off, snapmirrored=off, create_ucode=off,
convert_ucode=off, maxdirsize=5227, schedsnapname=ordinal,
fs_size_fixed=off, compression=off, guarantee=volume, svo_enable=off,
svo_checksum=off, svo_allow_rman=off, svo_reject_errors=off,
no_i2p=off, fractional_reserve=100, extent=off, try_first=volume_grow,
read_realloc=off, snapshot_clone_dependency=off
GGDEMO*>
GGDEMO*>
GGDEMO*>
GGDEMO*>
GGDEMO*> vol options volrootnew root
Volume 'volrootnew' will become root at the next boot.
GGDEMO*>
GGDEMO*>
GGDEMO*>
GGDEMO*>reboot
After Reboot
GGDEMO> vol options vol0
nosnap=off, nosnapdir=off, minra=off, no_atime_update=off, nvfail=off,
ignore_inconsistent=off, snapmirrored=off, create_ucode=off,
convert_ucode=off, maxdirsize=5227, schedsnapname=ordinal,
fs_size_fixed=off, compression=off, guarantee=volume, svo_enable=off,
svo_checksum=off, svo_allow_rman=off, svo_reject_errors=off,
no_i2p=off, fractional_reserve=100, extent=off, try_first=volume_grow,
read_realloc=off, snapshot_clone_dependency=off
GGDEMO>
GGDEMO>
GGDEMO>
GGDEMO>
GGDEMO> vol options volrootnew
root, diskroot, nosnap=off, nosnapdir=off, minra=off,
no_atime_update=off, nvfail=off, ignore_inconsistent=off,
snapmirrored=off, create_ucode=off, convert_ucode=off, maxdirsize=5227,
schedsnapname=ordinal, fs_size_fixed=off, compression=off,
guarantee=volume, svo_enable=off, svo_checksum=off, svo_allow_rman=off,
svo_reject_errors=off, no_i2p=off, fractional_reserve=100, extent=off,
try_first=volume_grow, read_realloc=off, snapshot_clone_dependency=off,
GGDEMO>
GGDEMO>
Regards
Moez ALIBHAI
There are a couple of things to watch out for. I do this fairly often and use the following process:
1. Enable NDMPD
2. ndmpcopy /vol/vol0 /vol/<new vol0>
3. cifs terminate
4. vol rename vol0 vol0_old
5. vol rename <new vol0> vol0
6. vol options vol0 root
7. Reboot Storage System
8. Test FilerView access. Normally this does not work anymore, so run "secureadmin setup ssl" to recreate the ssl certificate, and filerview should work again
9. vol offline vol0_old
10. Check access to C$ share
The reason for disabling CIFS is so when the vol names are updated the system does not automatically update the cifs shares with the new vol names.
Good luck
All good and good catch on the secureadmin.. I haven't seen a burt or kb on it but consistently ssl needs to be reset after move of root.
One additoinal step I add with ndmpcopy is to 'priv set advanced ; rm /vol/volname/target/restore_symboltable' to delete the symbotable file left behind by ndmpcopy. The other option is to 'vol copy start -S sourcevol targetvol' instead of ndmpcopy and restrict the targetvol then online it after. If data other than etc is in root (hopefully not) then vol copy is sometimes easier to also get all snapshots of the source volume copied to the target volume.
Just wanted to add that this works a treat.
We did on our filers only a few weeks ago and it is simple and effective.
Regards
ArthursC
A rather painful item that is left out here, which I've just finished dealing with.
May be related to the version of Data ONTAP, as I am running 8.0.1 7-Mode.
When using the ndmpcopy command, you have to include the -f switch or the system files are not copied over, and you wind up at the Setup Wizard after the reboot.
Example, ndmpcopy -f /vol/vol0 /vol/vol0_new.
Note: When you issue the vol options vol0_new root command, the filer will still warn you that the necessary system files are not present on the new volume. This can be safely ignored.
I haven't had that issue.. just ran it on 8.0.1P4 7-mode for a customer yesterday.. if the volume has had a copy already that would need it... probably not a bad idea to use -f anyway even if an empty volume to overwrite system files on the target with the source.
Haven’t had information on the volume before issuing the command.
The set of instructions I was following also had me restrict the new volume prior to issuing the ndmpcopy command, which may actually have been what caused my issue.
One of my guys just tried to run through the procedure and was still getting setup wizard after a reboot when the root volume was moved. Looks like ensuring the volume is online and not restricted fixed that problem.
I’ll have to update the post once I verify.
ahh restrict the volume only if doing a vol copy. But for ndmpcopy leave the volume online... the copy would assume /vol inside the root volume.. I bet if you ls /vol/vol0 you will see /etc and also /vol/vol0_new/etc inside vol0... it created a vol directory in itself since the volume was not online to receive the copy.
Here's the relevant KB article:
vol rename vol0 oldvol0 Rename existing volume to something different.
Resize oldvol0 volume to 260g Optional: Resize to 260GB for 8.x.x.
vol create vol0 aggr0 260g Create new vol0.
vol restrict vol0 Restrict new vol0 to enable copy.
vol copy start oldvol0 vol0 Start copy process.
vol online vol0 Online the new vol0.
vol options vol0 root Set the new volume as root.
reboot Reboot or CF takeover/giveback to enable new root volume.
vol offline oldvol0 Offline the old vol0.
vol destroy oldvol0 Destroy the old vol0.