This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I am migrating my NAS from an Ultra 2 plus (running OS 6.9.1), to a new RN524X. The new RN will have new WD Red Drives, starting out with just two drives, option to expand later.
What is the best way to move my data from the old readynas to the new one and retain all perms, etc.? I'd love it even more if there is a way to migrate over my compete installation setup, but I'm not sure if that's possible or reccomended or not. what are my options?
Actually the article you quote and that I also read doesn't make complete sense to me because it shows the SOURCE tab selected, but the fields shown don't match the SOURCE tab, they match the DESTINATION tab...
I think some of the screen layouts might have changed since the kb article was written.
In any event, the / in the path field definitely needs to be done on the SOURCE tab, not the DESTINATION. As you say, it's impossible to do it on the destination, since the path field there can't be blank.
The normal rsync backup jobs will migrate permissions and file attributes. Unfortunately folder creation time won't be transfered, but everything else will be.
It's been a while since I used NFS for these transfers. And when I did, I usually switched the backup job to rsync when it completed, and reran it - an old trick on v1 NAS to get the benefits of rsync without the relatively slow full backup speed.
Finally got my new RN524X and trying to rynsc over my main data share, but having problems with that. I am trying to use the backup gui in frontview (OS6.9.2) to do it.
I have tried to follow the following guide for rsync copy of a share on one readynas to the share by the same name on another readynas:
However the point about putting a "/" into the path of the destination does not work at all, it just gives an error. Leaving it blank gives an error. Typing in the name of the share there, ends up copying everyting over but in a subdir of the destination share, by the same name, which is not right either.
You don't need it when doing a "pull" backup, so I'm not sure where your issue is. You should probably review the kb guide.
wrote:
And I didn't understand your points about NFS, is that soe way to preserve all folder creation dates?
Normally I just use rsync these days and live with the folder creation problem. I don't recall if NFS works around that - in part because when I did run NFS I generally immediately switched to rsync and reran it. That's all I was trying to point out.
Yes I read the same article, its in that old thread and that is what I was referring to about the "/" but its not working. I am attempting a push transfer and Its not possible for the destination path to be empty. it gives me an error. Whatever value I put there will be a directory created on the destination share and the contents going inside that, rather then directly to the share. It doesn't make sense they would tell us to put "/" for the SOURCE path with a local-->remote transfer. But I can try that, but it doesn't matter bevacuse the form won't let me apply it unless I also provide some kind of path for the DESTINATION and that becomes a subdir on that DEST share...which is not desired.
Actually the article you quote and that I also read doesn't make complete sense to me because it shows the SOURCE tab selected, but the fields shown don't match the SOURCE tab, they match the DESTINATION tab...
Actually the article you quote and that I also read doesn't make complete sense to me because it shows the SOURCE tab selected, but the fields shown don't match the SOURCE tab, they match the DESTINATION tab...
I think some of the screen layouts might have changed since the kb article was written.
In any event, the / in the path field definitely needs to be done on the SOURCE tab, not the DESTINATION. As you say, it's impossible to do it on the destination, since the path field there can't be blank.
Yea so I got it to work, Used "/" for the path of source and on the DEST tab the name of the share for the path, which doesn't make complete sense, but it ran correctly copying share to share that way.
