with 120 NFS clients and just as many CIFS shares "fetching" is not an option, yearly, monthly and weekly oracle exports have to be available right away. No one is going to wait for me to export them, then for system admin to mount them. I am afraid the option i provided is the only way to move forward.
As you said you cannot do directory replication to a different MTree. You can also replicate the existing data to /backup on DD9500 and let it sit there till it expires ? and if any recovery is required you can fetch it from there. You can set all new backups to go to SMT shares.
i have a lot of customers and with 256 mtree limit i will run out of mtree pretty fast. Each business unit will have two mtrees, one for CIFS data and one for NFS.
Moving customers into mtree on source will force me to cause two outages for the customer, one to move them to an mtree on source DD and then another outage to cutover to new DD.
dynamox
9 Legend
•
20.4K Posts
0
August 3rd, 2016 20:00
with 120 NFS clients and just as many CIFS shares "fetching" is not an option, yearly, monthly and weekly oracle exports have to be available right away. No one is going to wait for me to export them, then for system admin to mount them. I am afraid the option i provided is the only way to move forward.
gautamgp
226 Posts
1
August 3rd, 2016 20:00
As you said you cannot do directory replication to a different MTree. You can also replicate the existing data to /backup on DD9500 and let it sit there till it expires ? and if any recovery is required you can fetch it from there. You can set all new backups to go to SMT shares.
dynamox
9 Legend
•
20.4K Posts
0
August 4th, 2016 06:00
i have a lot of customers and with 256 mtree limit i will run out of mtree pretty fast. Each business unit will have two mtrees, one for CIFS data and one for NFS.
Moving customers into mtree on source will force me to cause two outages for the customer, one to move them to an mtree on source DD and then another outage to cutover to new DD.