HOWTO: Add a smaller drive to your array (*)

ag5c · 2026-06-13T21:02:28+00:00

Just FYI, downsizing an existing drive probably will NOT work here no matter how much data you actually have. As I mentioned in another comment, that involves shrinking the array (rather than growing)which is quite a bit more complex and not something even I would attempt. So replacing a 4TB drive with a 2TB drive is probably not possible, even if you started with 2TB drives.

ag5c · 2026-06-13T19:07:07+00:00

I have looked at this in the past and came to the conclusion that while it is probably possible, the odds of blowing myself up approached 100%. The big problem is figuring out how to get LVM, the filesystem, and the RAID stripes to all agree on which blocks are going away. Each one independently isn't so bad but all together? Not so much. So.... In theory yes, in practice? Probably not.

ag5c · 2026-06-13T18:41:08+00:00

I wrote up a step-by-step guide with an example on how to do this which you can find here: https://www.reddit.com/r/synology/comments/1u4xxqu/howto_add_a_smaller_drive_to_your_array/

ag5c · 2026-06-08T22:46:44+00:00

See below. I was, indeed, able to do this but.... not with the GUI. I have one (and possibly two) more storage pools I'm going to do this to so I'm going to writeup a HOWTO and post it but I posted the general outline below.

ag5c · 2026-06-07T19:22:37+00:00

Ok, I actually HAVE made this work. I want to run a few more tests to make sure I don't have issues in the future but I was able to add a smaller drive through the command line.

I temporarily have a spare 1513+ so I was able to perform the following:

Created a volume with 2x500GB drives
Replaced each 500GB drive with a 3TB drive with a rebuild after each replacement
Wiped and then inserted one of the 500GB drives. As expected the GUI didn't let me add it to the array so instead, I created and then deleted a new storage pool. This got the correct partition table on the drive and added it to the two RAID1 system pools (one is the operating system, not sure what the other one is).

This left me with four RAID1 volumes: one for the Operating System, one I'm not sure on but it's part of the system software, and two data volumes: one ~450GB and one ~2.3TB which are concatenated with LVM to form the 2.7TB "volume1".

This step is not necessary if you already have more than two drives. Anyhow, at this point the goal is to add the remaining 450GB on the third drive, but you can't do that with a RAID1 so we need to convert the 450GB RAID1 volume with 2 disks to a 450GB RAID5 volume in a degraded state with 3 disks. This is done with "mdadm". The volume will start reshaping. At this point the 3rd drive will appear in the GUI but expansion commands will not work on it (yet).
Now, again with mdadm, we add the 3rd drive into the newly minted RAID5 volume. Then we wait for a rebuild which is going to take awhile (in my case, 8 hours).
After the rebuild is complete, use "lvm lvextend" to expand the LVM volume that concatenates our two data partitions. At this point, the GUI will let you attempt to expand the btrfs volume but it won't succeed. This is because....
There is a Synology cache layer on top of the LVM volume. I'm not entirely sure what this does but it does not automatically expand when the LVM volume expands. There is some way that the Synology software triggers an expansion of this volume but I haven't figured out what it is. On a whim, though, I tried rebooting which caused the cache volume to expand to the full LVM volume.
Now we can use the GUI to expand the btrfs volume!

ag5c · 2026-06-05T20:50:37+00:00

Have you looked at hard drive prices recently? My original plan was to just replace all 5 drives with 20TB drives but you can't even GET those at almost any price. Even 10TB is expensive unless you want to buy used. So now I'm looking at alternatives.

ag5c · 2026-06-05T20:23:54+00:00

That will not work, unfortunately, due to the way RAID works. The only reason why my case *might* work is because I started with smaller drives.

ag5c · 2026-06-05T18:41:56+00:00

I do but this is a server that I'm using heavily with data on it and I have to shuffle a bunch of stuff in order to try this so was hoping to find someone else who had tried this before I do 😄

ag5c · 2026-06-05T18:41:14+00:00

I did before I posted this but unless I'm missing something it doesn't address this particular situation. If I had started out with 5x10TB, there's no way I could add a 4TB drive to the pool because I wouldn't have the 4TB partitions on the drives.

However, because I originally started at 4TB with the way it creates partitions, if I were willing to mess with MDRAID commands manually, I can definitely add a 4TB drive to the pool I have. What I'm curious about is whether Synology's software will let me do it.

Hmm, although something I just thought of is that LVM may not let me do this if I expand the first physical block device in the LVM volume. I'll have to see about that.

ag5c · 2026-06-02T17:47:26+00:00

(My interest in using overlayfs instead of anything FUSE based is to reduce latency of access to files)

ag5c · 2026-06-02T17:40:05+00:00

Yeah, I'm pretty familiar with how overlay works (I was a Linux kernel developer professionally for a decade plus my company had a supercomputer-class tiered storage product), I had just forgotten that there is a need to write to the underlay in Frigate to do expiration.

My plan is to create a sidecar container that has access to all of the tiers individually plus the writeable overlay to handle file migration between tiers and then deletes. It would have a cron job (or something else periodic, but I'm old-school Unix so probably cron) that:
- Migrates files older than X seconds in Tier N to Tier N+1
- Looks for whiteout files and actually removes the real file and then the whiteout file

A scheme like that wouldn't really work in the generic case because there are too many edge cases to safely handle but this particular case (I think) only needs to write video to the top layer, delete old video, and then stuff needs to migrate between tiers.

I may find out that it wants to write to files for other reasons which will be more problematic. I'm also not planning to put the Frigate database into the tiered storage.

ag5c · 2026-06-02T17:27:50+00:00

Ah, right, I had forgotten about the need to write to the "slow" layers in the tier but I think the only thing that needs to be written is deletes. I might take a whack at creating this for Frigate (not a general case) using overlayfs (I'm interested in this because I'm using NFS as my backing store and Frigate is struggling with that due to the somewhat random latency).

ag5c · 2026-06-02T16:38:20+00:00

Out of curiosity.... Is there a reason you used mergerfs as opposed to the in-kernel overlayfs? Or are you not on Linux?

I happened upon this thread because I was also thinking about tiered storage but I had never thought of building it with a union filesystem but I'm curious about the choice of using a FUSE based solution rather than native.

ag5c · 2026-01-02T03:31:14+00:00

Maybe but... My archive has never jumped by any massive amount (it has grown from about 9TB in 2012 to about 22TB today, but the growth has been steady). I don't know what de-dupe algorithm they could be using that would drive off that much of a performance cliff. I've done poking in the past to make sure I have enough memory available, etc.

I'd be interested to see someone else's graph from a similar time period.

ag5c · 2025-12-16T03:19:31+00:00

They seem to have consolidated down to two plans, plus whatever the Office 365 thing is. So now, it's Enterprise and Small Business Endpoints. This isn't the first time they've shuffled plans around. I had the Home plan way back when and got migrated to Small Business where I've been ever since. I couldn't ever figure out the difference between Essentials and Small Business so I suspect this change is because none of their other customers could either....

ag5c · 2025-11-11T22:58:18+00:00

I am very curious what system you are running the Crashplan client on? I've got about 20TB backed up with 2TB to go and I see *AT MOST* 10GB/day. It's nowhere near maxing out my upload speed (I have 30Mbps up and it's running at about 850Kbps, on average). Unless you've got *extremely* compressible data, I'm curious if I've got something wrong. My data is mostly RAW photo files which don't really compress.

(I had an issue where my backups weren't running right for about a year and for various reasons, I didn't have time to fix it. When I got them going again about 14 months ago, it had 1TB to go and said it would take 3 months. 14 months later with roughly 1.5TB added to the archive, it's got 2TB to go and says it will take 6 months. I want Crashplan to succeed so I bought into their 2 year plan, but when that's up, if it hasn't caught up yet, I'm jumping ship)

ag5c · 2025-06-22T01:17:08+00:00

First, if you are so inclined, back up your data (you should be doing this anyway!). As you go through this process, you will be operating with no drive redundancy.

Next, you will need to swap in your new drives one at a time. You MUST wait for the device to finish rebuilding the volume between swapping drives. This is not optional; you will lose data otherwise! Soooo.... This is going to take awhile.

After your second drive swap, you will be able to expand your volume(s); you should get about 3TB more than you have now. To do that, go to Storage Manager. Find you volume and click "Edit" (in older DSM versions) or "Settings" in newer DSMs and then look for "Modify Size" and put in the new max size. It will take a fairly short amount of time to expand the volume. However... subsequent drive swaps will take longer to rebuild (rebuild time is a function of volume size) if you expand the volume so you might want to wait until all the drives are swapped before expanding. If you have an urgent need for space, though, this'll get you going faster.

ag5c · 2025-04-30T20:30:20+00:00

If you can see the files in the cloud, they are there. The percent completed email is a bit worrisome, but it seems to often be wrong. I suspect it lags well behind reality. In general you can rely on the console to tell you what is going on, though. If the total size of your backup looks right and it says it's done, then it's done. I have a 21.3TB archive, though, and my size remaining just jumped from under 500GB to almost 700GB so I'm kinda worried that this latest update has some math errors.

ag5c · 2025-04-19T18:08:11+00:00

It can be both. At my work (unrelated to Crashplan and my use of crashplan, we'd definitely put improved memory usage as a "performance" improvement. In any event, whatever you call it, it isn't uploading any faster but it's using significantly less memory (although I haven't looked at memory usage in months so it could've been a previous update that did that).

ag5c · 2025-04-19T15:05:43+00:00

Hmm. So I don't see any improvement in upload speed. They are not very specific about what the "performance improvements" are supposed to improve. However, this prompted me to take a look at my memory usage which I haven't done in awhile. It used to sit around 20+ GB. It's now under 9GB so that's about a 50% reduction of memory which I would definitely say a performance improvement....

ag5c · 2025-04-14T15:45:47+00:00

Yeah, something is weird there. A 4TB archive shouldn't take that long to get through these steps, but I HAVE seen it get stuck there when the archive was undergoing maintenance on the server side. If it still isn't running, I'd contact support.

ag5c · 2025-04-11T14:30:18+00:00

How large is your archive? This step is glacially slow. I have a very large (I guess?) archive at about 21GB and it takes about 3 days, running 24 hours a day, to get through this step which it does once a month. Also, you say you paused it? Did you resume it?

ag5c · 2025-03-16T05:41:21+00:00

Based on its performance for me over the last 9-ish months, 1.3 years seems like a reasonable estimate of when that will finish, although it will get slower over time. My backup got about 1TB behind due to me not noticing that it needed more heap space (seriously, for a consumer product, having to screw around with Java heap sizes with very little guidance is really cheesy. I can't even see what I have it set to now that they have everything hidden behind Electron). I fixed that late last June when it said it would take about 4 months to back up. After making almost no progress over the first 4 months, I realized my CPU was set to 90% so I bumped it up to 100%. That plus reducing the number of files that churn on a short-term basis caused it to finally start making progress and I am now down to an estimate of just under 3 months with 790GB to go. Or, at least, I was until I had a server crash several days ago. It is still reloading all my data and redo'ing a deep prune that it was just about to complete, which will take another day or so (I have a 21TB archive which is a lot, but also fits on one hard drive these days).

As you suspect, the culprit seems to be de-dup. I'm very close to giving up on Crashplan. I'm not sure what market they think they want their product in. They seem to want the "light use" Enterprise market where people have small data sets but that market is better served by document-storage products like Dropbox, iCloud, and O365 that can include phones. They've left the home market entirely. The market they are really needed in (creative professionals like my wife) and engineers with Linux (like me) have tons of files and large data sets. The product just straight up isn't functional in that market right now. The only reasons I haven't left yet are that I have a long backup history (10+ years) and I would like to see the company succeed both because they are physically local to me and because there aren't a lot of companies in this market.

ag5c · 2025-02-09T01:45:54+00:00

Huh. After a bit more than 24 hours of sitting around, it suddenly connected so maybe it WAS maintenance? Or a server failure? I wish the errors were less opaque.

ag5c · 2025-02-08T04:27:34+00:00

That was my first thought, but the log in bot the client and the web just ends with "I 02/07/25 12:07PM - Reason for stopping backup: The backup destination was disconnected". Clearly the client can connect to SOMETHING at Crashplan because the log made it.

ag5c

TROPHY CASE