Forum Replies Created
What you’re running into is pretty common—disk-based backups grow endlessly if there’s no lifecycle policy. Moving to a 30-day rolling backup on your NAS and pushing completed projects to LTO is a solid approach. Also, consider splitting “working storage” and “backup storage” more strictly—using the same system for both can get messy over time.
Your hybrid idea actually makes a lot of sense. Using your Synology units for short-term DR and LTO for long-term archive is pretty much how a lot of studios handle it. For LTO software, you might want to look at LTFS-based workflows or something like YoYotta—it’s much more stable for large media archives compared to older tools like Retrospect.
This kind of issue is pretty common after an improper shutdown. The NAS might be stuck trying to sync but failing due to a timeout setting or system load. If your Ugreen NAS has an option to stop the current task or restart RAID management services, try that before re-initiating the repair.
Since it’s RAID 1, your data should still be safe on at least one drive. If you’re nervous, the safest move is to back up the accessible data first before doing anything else. After that, you can retry the repair or even remove and re-add the secondary drive to force a rebuild.
<p data-start=”381″ data-end=”682″>If the repair task keeps timing out, it could be because one of the drives is responding slowly or hitting read errors. Even if SMART shows “healthy,” the disk might still be struggling. I’d suggest running a full SMART extended test on both drives before attempting the repair again.</p>
A sudden power cut can definitely cause a RAID 1 array to go into a degraded state even if both drives are physically fine. It’s often a sync or metadata issue rather than actual disk failure. Before retrying the repair, try rebooting the NAS again and check system logs to see why the rebuild is timing out.
I’d avoid putting both old drives into the new unit right away. Start with just one disk and see if the new NAS can detect the existing volume. Synology systems are usually pretty good at importing drives from older models, especially when moving between similar setups like this.
Since you were running RAID 1, you’re in a pretty good position. Each drive should contain a full copy of your data. The safest option is to insert one of the drives directly into the new Synology DS224+ and let DSM recognize it. Just be very careful during setup and avoid anything that says “initialize” or “format.”
If the data is important, I’d honestly avoid too much trial and error. A freezing drive can degrade quickly and make recovery harder the more you stress it. Cloning with error handling is your best DIY shot, but if that fails, professional recovery might be the safer route—especially for RAID setups where rebuild attempts can overwrite critical metadata.
The “entire thing is buggered” advice is a bit of an exaggeration. RAID is designed to handle failures, but a partially failing drive (freezing, not fully dead) is actually worse than a completely failed one. It can cause timeouts and instability. If possible, take the bad drive offline and work on cloning it separately rather than keeping it in the live array.
Cloning a failing RAID drive can work, but you have to approach it carefully. A standard clone might fail if the disk keeps freezing. You’d want to use something like ddrescue that can skip bad sectors and come back later. Also, make sure you clone it to a drive of equal or larger size. Once cloned, you can try rebuilding the array with the replacement.
It’s not automatically “game over” if one drive in a RAID setup starts freezing. It really depends on the RAID level you’re using. For example, RAID 1 or RAID 5 can usually tolerate a failed drive. The bigger risk is that a freezing drive can slow down or hang the entire array, which makes recovery trickier. Cloning is possible, but you’d need to use a tool that can handle bad sectors and doesn’t stop on read errors.
You’re actually in a better spot than it might feel right now. This kind of issue—where a RAID suddenly shows up as RAW after being unplugged—is usually down to corrupted file system or RAID metadata, not the drives themselves failing. That means your data is often still there, just not being read properly. The key thing now is to avoid doing anything that could overwrite or confuse the RAID further—like initializing it, formatting it, or trying random rebuild attempts.
If the files are important, it’s worth going straight to a professional recovery lab like WeRecoverData or Flashback Data. These guys deal with RAID setups all the time and can usually piece things back together even when the structure is damaged. Overall, this isn’t a worst-case scenario—you’ve got a solid chance of recovery as long as you handle the next steps carefully.
At this point, the smartest move isn’t to stress over rebuilding your old setup exactly the way it was. You’ve actually come out of this in pretty good shape—your RAID is intact, your data is safe, and your PBS backups are there. That’s what really matters. Instead of trying to recreate every logical volume and thin pool from memory, it’s much simpler (and safer) to treat this like a clean Proxmox install. Unlock your RAID, mount it, reconnect your PBS datastore, and restore your VM—that process will bring back most of what you need automatically. Losing /etc/pve might feel like a big deal, but in practice, it’s not a blocker since configs can be rebuilt or restored along the way. Think of it less as rebuilding from scratch and more as setting things up fresh and then pulling your system back in from backups. It’s quicker, cleaner, and avoids a lot of unnecessary headaches.
What you’re running into is pretty common—disk-based backups grow endlessly if there’s no lifecycle policy. Moving to a 30-day rolling backup on your NAS and pushing completed projects to LTO is a solid approach. Also, consider splitting “working storage” and “backup storage” more strictly—using the same system for both can get messy over time.