Aaand, in my morning stuper, I goofed while following the directions for changing to XFS.

 

I started copying the next disk to the wrong disk. (The previous disk I just filled). A quick google suggested I hit Ctrl + Z to halt the process... now I'm wondering what do I do next?

 

That rsync command is just copying files, so I guess I can go and manually see what copied over to the wrong drive and delete, then start the process again. Is there a better way?

 

Upon looking further, I can't be sure that the disk I was copying TO didn't have any of the same directories, in which case figuring out what to "undo" won't be trivial. Would Unraid be confused by seeing the exact same files within a share in multiple locations?

 

When browsing the disk I wrongly started copying to, I come across one of three scenarios:

 

[*]The top level folder (ie share) says "[dir] is not accessible. You might not have permission to use this network resource. The handle is invalid. - These are directories that were being copied from my source disk.

[*]I can open the folder and access all the contents within. These folders do not exist on the source disk so I know it's data that was on this 'wrong destination' disk to begin with

[*]I can access the top level folder and when compared to the source disk, it too has a folder by the same name. I can only assume that both disks were being used for the share.

 

I guess my biggest fear is losing data on the wrong source disk. Hopefully nothing would have been overwritten.

 

Is it possible to get a log of files that were transferred after the fact?

I guess the answer is nothing.

 

I hope for the best that nothing had the same filename and got overwritten. Otherwise, it was just data being copied from disk to disk. Eventually I'll go through it and consolidate.

 

In the meantime, I started a new screen session and started the transfer to the correct, empty xfs disk.

What command were you using to move the files?

 

Generally speaking, for user shares, it doesn't matter which disk a particular file ends up on, as long as it's in the correct folder. For one file to overwrite another its path and name have to match exactly.

 

I was following RobJ's instructions (linked in my first post). rsync -avPX

 

Yeah, I don't think that's likely. I do however wonder how Unraid behaves when data is accessed from a share, and the exact same share data exists on multiple drives?

 

(Because I copied some to the "wrong" destination, and am now in the process of copying it to the right one.)

The rsync command you gave implements a copy, not a move, so the original files should be exactly as they were on the source disk. Having multiple copies within a user share is not in itself an error but if you write changes to a duplicated file then problems will occur because only one copy will be updated and you wont know which.

 

Did you know that you can browse user shares within the GUI and it gives you information about which disks each folder and file is stored on? That should help you find the duplicates manually. This thread and those linked from it might help too: https://lime-technology.com/forum/index.php?topic=39607.0

 

The unaccessible folders you mention will have been created but permissions not correctly set since you aborted the process. You can delete them.

 

Incidentally, Ctrl-C is the keypress to kill a task. Ctrl-Z merely pauses it. http://unix.stackexchange.com/questions/135077/ctrl-c-vs-ctrl-z-with-foreground-job

 

Thanks for the replies. Yes I still have a screen session with the original transfer paused. I'll cancel it now. I did start a second screen session to carry out the intended copy.

 

I forgot about being able to browse the shares like that.

 

The inaccessible folders you mention will have been created but permissions not correctly set since you aborted the process. You can delete them.

 

Right, however, can I be sure (I was just guessing) that any top-level folders on the destination disk didn't merge with a pre-existing folder of the same name, with other contents? I guess I get the answer to that by investigating via the GUI as suggested.

 

I'll check out the link too.

Any newly created folders will be owned by root, since that's the user under which you ran rsync. Had you allowed it to run its course they would have been changed to match the ownership on the original disk - user nobody or one you have set up. You can check their contents by telnetting or sshing in and using the ls command or Midnight Commander - whichever you feel comfortable with.

 

Any newly created folders will be owned by root, since that's the user under which you ran rsync. Had you allowed it to run its course they would have been changed to match the ownership on the original disk - user nobody or one you have set up. You can check their contents by telnetting or sshing in and using the ls command or Midnight Commander - whichever you feel comfortable with.

 

I follow, and will definitely be verifying contents as I'm a bit puzzled that I'd have a top-level folder on a disk (share) be accessible while only *some* of its sub-folders are. It just doesn't make sense to me since I don't think any of them existed on this drive before. Yet only the inaccessible ones show a modified date of Monday. Anyway, I'll investigate. Thanks for your help.

 

Oh, and I made this comment in the other thread too but - it's definitely worth running rcvPX after a disk copy (RobJ mentions it as an optional step). The two drives I have taken the time to run this on have had files to copy over (and not because the disks were in use). The last one had 30 transfers to do! As it was storing a lot of photos and home video, I was happy to take the time to do it and will be doing that step for the remaining drives too.

I gotta say, this hasn't been the most fun process.

 

Now my desktop BSOD'd and I'm staring at a "There is no screen to be resumed." Apparently the last restart I forgot to start a screen session.

 

So... I'm poking around looking at rsync commands to figure out what I should run to resume the transfer I had going?

 

Edit: seems as though because there's a P in the command, I should be able to reissue avPX and it should start from where it left off?

Yes, -P, --partial - keep partially copied files in case of interruption.

 

Yes, -P, --partial - keep partially copied files in case of interruption.

 

That flag mean that if only 50% of the file (not files) got copied, then it won't delete the destination if the rsync was interrupted.

 

My standard rsync flags are -avXHq --delete which will only copy over changed files (ie: it will resume where it left off), and deletes any files on the destination which do not exist in the source

 

Thanks Squid,

 

Good to know.

 

My last disk just finished transferring and I'm leaving the spare disk in the array. Now everything is formatted as XFS. I shifted drive slots (what was in 4-7 is now in 5-8, and what was in 8 went to 4).

 

It's running a parity check now which still has a few hours left to go and already 169 sync errors have been found. Should I be concerned?

Thanks Squid,

 

Good to know.

 

My last disk just finished transferring and I'm leaving the spare disk in the array. Now everything is formatted as XFS. I shifted drive slots (what was in 4-7 is now in 5-8, and what was in 8 went to 4).

 

It's running a parity check now which still has a few hours left to go and already 169 sync errors have been found. Should I be concerned?

Parity should have been maintained so there shouldn't be any sync errors, depending on the details of what you actually did when you were following the directions you linked.

 

Probably best if you fully understand how parity works before trying that method then you would know how that method works to maintain parity and that you shouldn't expect any sync errors.

I'm running the check again to see if there are any more a 2nd run through. So far, 47% & 0 errors.

 

Edit: 100% and no errors.

 

I believe I had a process running that must have been changing files after the rsync process. I guess I'll never know specifically what files were affected.