Unsolved
6 Posts
0
1229
August 4th, 2020 18:00
VNX 5300 unified checkpoint savvol deletion steps
@dynamox
We have ip replication between two vnx5300.
we have 10 PFS. File pool free size left is only 1TB. Total file pool size is 120TB. 90TB is allocated to the 10*PFS combined and 19TB is allocated to checkpoint FS.
The network in secondary site is setup such that if I failover replication to destination VNX then it will not be able to reverse synch. So I do not have any option to switchover and run the script by EMC to resize the savvols.
so am thinking of deleting savvol of a single PFS.
Let me know if the following commands and procedure is correct:
Steps: Let me know if the steps are correct ?
1) delete regular checkpoint FS on source VNX is for example:
nas_fs -d id=1121 -o umount=yes
+ similarly for all remaining Daily and Weekly ckpts
2) stop and delete replication session (PFS-to-site2 is the session name) on Source VNX :
nas_replicate -stop PFS-to-site2 -mode source -background
nas_replicate -delete PFS-to-site2 -mode source -background
3) delete replication ckpt Filesystem on SourceVNX and check the file pool free size:
nas_fs -d id=915 -o umount=yes
nas_fs -d id=916 -o umount=yes
4) delete regular and replication ckpts on Destination VNX for PFS PFS and check the file pool free size.
5) create replication session for file system PFS with session name PFS-to-site2 on source VNX:
nas_replicate -create PFS-to-site2 -source -fs PFS -destination -pool Pool 0 -interconnect site1-site2 -source_interface ip=10.x.x.1 -destination_interface ip=10.y.x.2 -max_time_out_of_sync 10
6) Check file pool free size and savvol size on Source and Destination VNX for PFS
nasadmin@vnxsite1 ~]$ nas_replicate -info PFS-to-site2
ID = 174_APM0012440xxxx_2007_502_APM0012030yyyy_2007
Name = PFS-to-site2
Source Status = OK
Network Status = OK
Destination Status = OK
Last Sync Time = Tue Aug 04 16:27:17 EDT 2020
Type = filesystem
Celerra Network Server = Site2NASMGMT0
Dart Interconnect = site1-site2
Peer Dart Interconnect = site2-site1
Replication Role = source
Source Filesystem = PFS
Source Data Mover = server_2
Source Interface = 10.x.x.1
Source Control Port = 0
Source Current Data Port = 52844
Destination Filesystem = PFS
Destination Data Mover = server_2
Destination Interface = 10.y.x.1
Destination Control Port = 5085
Destination Data Port = 8888
Max Out of Sync Time (minutes) = 10
Current Transfer Size (KB) = 612352
Current Transfer Remain (KB) = 228352
Estimated Completion Time = Tue Aug 04 16:37:14 EDT 2020
Current Transfer is Full Copy = No
Current Transfer Rate (KB/s) = 38027
Current Read Rate (KB/s) = 8237
Current Write Rate (KB/s) = 2038
Previous Transfer Rate (KB/s) = 40143
Previous Read Rate (KB/s) = 8419
Previous Write Rate (KB/s) = 2202
Average Transfer Rate (KB/s) = 22336
Average Read Rate (KB/s) = 7266
Average Write Rate (KB/s) = 1744
saintly_guy
6 Posts
0
August 4th, 2020 18:00
I have gone through other such posts but they are very old and my situation is a bit different because I don’t want to switchover replication and use the script provided by emc in primus emc314313
DELL-Sam L
Moderator
•
7.6K Posts
0
August 6th, 2020 09:00
Hello saintly_guy,
it is best to contact support for assistance in what you are trying to do. If your system is out of support, then here are some KB that should be of assistance as well.
https://dell.to/30wjHpK
https://dell.to/30yRKh9
https://dell.to/2C36tas
https://dell.to/2C4XOnX
https://dell.to/2Px9Vx8
saintly_guy
6 Posts
0
August 6th, 2020 11:00
Hi
Both VNX boxes are under support contract. So the support team should be able to resize the savvols under break-fix SR?
DELL-Sam L
Moderator
•
7.6K Posts
0
August 6th, 2020 15:00
Hello saintly_guy,
If you have tried to do the resize as stated in the KB’s & it fails, then support can look into that & see what is needed to get the resize to complete.
saintly_guy
6 Posts
0
August 8th, 2020 01:00
Will the script delete regular checkpoints as well?
Dell-DylanJ
4 Operator
•
2.9K Posts
0
August 11th, 2020 10:00
Hello,
I'm not seeing an indication that they will, but I'd agree with Sam where he said that contacting support would be the best choice. Since the VNX systems are under contract, having a specialist to talk to would probably be very helpful.