Best use of DrivePool + Snapraid: replace a drive

[xliv]

Hi,

I was looking for a specific topic or wiki page of the tips & tricks to best use DrivePool + Snapraid together.

Today, my question is about: how to replace a drive with a larger one.

• "DrivePool way": you simply can add the new drive and remove the old drive from the pool, the rest is done automatically. Problem with Snapraid is that, if by chance (or right balancing config) the content of the removed drive ends up on the new drive, the paths to each file will have changed, so Snapraid will report a massive deletion / creation of files, and the sync command may take 12-24h to run...
• "Snapraid way": copy (with robocopy) the content of the old drive to the new, change the config with the new drive, run a diff and fix potential "changes", and once everything seems ok, run a sync (which should be immediate). The problem here is you'll end up with the old PoolPart folder, which I guess DrivePool will not cope with.

Is there a preferred way to do this? Right now I did it the "DrivePool way", and the sync command reports 12h (I replaced a 4TB with a 12TB, so moved approx 3.5TB of data).

What I would loooooooove would be a deep integration with Snapraid, and potentially (why not) a Snapraid UI in DrivePool...

[Umfriend]

I do not have SnapRaid but from what I have read, I think I would have done it as follows (I am assuming that DP is set not to rebalance because that might cause a lot of files being from other drives even to the new 12TB drive):

1. Add net drive to Pool;
2. Stop DrivePool Service;
3. Robocopy from the old drive everything *within* the hidden PoolPart.* folder to the hidden PoolPart.* folder on the new drive;
4. Either delete from the old drive or physically disconnect/remove it;
5. Change Snapraid config file;
6. Restart DrivePool Service (or reboot pc);
7. Remove old drive from Pool (through DP GUI).

Or somesuch.

[xliv]

Many thanks!

Ok I'll do this next time, and will report here about if (and how much) the fact that all paths have changed (PoolPartA to PoolPartB) impacts Snapraid.

It's actually probably very similar to what I've done (except that instead of using robocopy, I've let DrivePool handle the move, since my config was set to be sure that the data would be moved only to the new drive. But maybe robocopy does a better job at keeping the file attribues the same.

[Umfriend]

I wouldn't know what it the best option. Given how comfortable I am with DP, I would have done it the same as you (I realise I proposed another scenario in my previous post but that would have been my way to go *if* I minded SnapRaid having to work for 12 hrs).

[xliv]

I tried the following:

• Add new drive
• Robocopy data from the poolpart folder of the old drive to the new drive
• Insert drive in DrivePool, then stop service to move files to the new poolpart folder, restart service and remeasure pool
• Edit Snapraid config to replace the old drive by the new
• Diff command => massive "copy" and "remove" of all files
• Sync (with option --force-empty as otherwise sync does not work) => takes 20h for 5TB

There's got to be a better way...

I was thinking about putting the PoolPart folder instead of the root of drives ni SnapRaid config. Would that work?

There is a trace "WARNING! UUID is changed for disks: 'd2'. Not using inodes to detect move operations."

Maybe using the --force-uuid option instead, or together with the option --force-empty. I'll try next time.

I know this is not the Snapraid forum, but I would have thought more people used both at the same time (they complement each other very well).

[xliv]

The more I think about it, the more I think I should have configured Snapraid to the content of the PoolPart folders.

That way, moving the content of 1 drive to a new one would have kept the parity untouched. Of course, it protects only the content of the pool (meaning nothing outside of the PoolPart is protected), but in my case I don't mind as my drives are purely for use by the pool.

Would there be a problem with that?

For example, the snapraid.content files are at the root, so out of the PoolPart folder, and therefore are not part of the area protected by parity. Are those files skipped anyway when computing parity? I would assume so, they are changing while computing the parity during the sync command.

[shaquille.oatmeal]

1. Yes, it is not only, ok, but actually recommended to configure Snapraid to the content of PoolPart folders. You can search for "Snapraid with drivepool" on Google for example conf files.

2. Yes, it's ok to have snapraid.content outside the PoolPart folder, because (I haven't confirmed this but believe so) snapraid.content is protected through an related but separate system than the "sync between drives", because you could have 100 snapraid.content files. This system is also the reason why it's required to have at least N+1 snapraid.content files (where N is the count of parity drives).

[mpeterson]

This method worked for me:

• Connect and format new drive
• Add drive to drivepool to create poolpart folder
• stop both services (snapraid and drive pool)
• robocopy data from old drive pool to new drive pool folder
  •     robocopy F:\PoolPart.xxxx K:\PoolPart.yyyy /e /copyall
• copy snapraid.content file if applicable
• edit snapraid conf
  •     comment out (#) old data disk line (e.g. "data dx F:\PoolPart.xxxx" becomes "#data dx F:\PoolPart.xxxx"
  •     add new data disk line using old "dx" with new drive letter and poolpart folder (e.g. "data dx K:\PoolPart.yyyy")
  •     update content line if applicable
• run snapraid service
  •     run a diff and fix potential changes until "diff" reports only "equal", "restored" or "copied" files.
    •         snapraid diff
  •     run a "check" audit command limited to the replaced disk to check the check-sum of all the files (replace "DISK_NAME" with "dx")
    •         snapraid check -a -d DISK_NAME
  •     once everything seems ok, run a sync which should be immediate
    •         snapraid sync
• run drive pool service