How do I replace a failing disk NOT in a RAID?

Take a look at Data Backup in this Guide.

There's a section that describes how to set up disk-to-disk RSYNC backup (disk replication) and it will tell you how to redirect your shared folders, to the new disk, when the copy is complete.

You'll find version info under; Diagnostics, System Information. It's in the Overview or Report tabs.

Zitat von crashtest

You'll find version info under; Diagnostics, System Information. It's in the Overview or Report tabs.

Zitat von Tom_G_2010

Steve,

Where you able to work through all this?

I am now facing a similar situation. I have a 1.4Tb drive that currently has 3 shared folders on it that is throwing more and more frequent errors. I have a new 4Tb drive available to replace it.

I read through the guide material referenced above by Crashtest but I'm just not putting it all together.

I could really use a little guidance on this if anyone has the patience to go over the basic process.

Thank!

Alles anzeigen

Install, Format and Mount the new drive.

Create 3 corresponding shares on the new drive.

Set up a simple rsync job to sync Folder A (on old Disk) to Folder A (on new disk).

Run rsync job.

Rinse and repeat for next two folders.

When your done, remove shares on old drive from any plugins, etc.

Delete shares on old drive under shared folders.

Point plugins, etc. at new appropriate folders on new drive.

Unmount the old drive filesystem. If you've removed all the shared folders, removed all plugin references, etc.. it should unmount no problem.

Shut down and physically remove old drive.

That should do it.

What both KM0201 and HannesJo described above will work fine. The best, easiest to understand, most complete explanation of backup and RECOVERY is found on page 59 (OMV 5) of @crashtest’s Getting Started with OpenMediaVault. It’s on page 64 of the guide for OMV 4. You need to have an always installed backup drive and a backup strategy in place with a REAL recovery feature. That is if your data (and time) is important to you.

Zitat von ekent

I don't have any issues with my drives at the moment, however trying to be prepared and think about that time when I will need to look at replacing drives. RSnapshot does incremental backups and by default completes hourly, weekly, monthly etc backups. How does this work with re-pointing my shared folders to the backup drive? Does some sort of cleanup of the different backup types need to be performed before the shares can be re-pointed to my backup drive?

While you're getting "versioned" backup with RSnapshot, the user must know what a "snapshot" is and which snapshot (a specific time frame) to select for restoration. Further, Rsnapshot is a per-share back up meaning that a separate copy operation (per share) would be required from the backup directory to a new drive or partition. Bulk copies from the CLI or with something like Midnight Commander would be involved. Then, after that's accomplish, restoration would still required repointing existing shares to a new drive. All of that boils down to, decisions and "Complexity".

**If I got the overview explain of an Rsnapshot restoration wrong, someone please chime in and explain it correctly.**

Backup is important but a usable restoration process, for the broadest possible cross section of users, is even more important. If a backup can't be restored, easily or at least within the tech abilities of the user, the backup is useless. In contemplating what would work well for new users, where restoring a backup could be explained in relatively easy and discrete "steps", an Rsync drive-to-drive copy seemed to make the most sense. During a restoration, simplicity is key to preventing mistakes and the loss of data. When writing the user guide, simplicity was the top priority.

With Rsync, as implemented in the user guide, the backup up drive can replace the main data drive, by simply repointing base shares to the new drive. Everything is there, as it was during the last backup of the source drive. All services that are applied, permissions, etc., that are layered onto the base shares of the source drive, follow to the destination drive. Since the destination disk is already installed, no new hardware is needed or other interventions required, to complete a full restoration.

_______________________________________________________

The down side of Rsync - no versioning:
Once a drive-to-drive copy is made, there's no going back. The previous copy is gone. The reason this should be taken into account is, if the Rsync operation is automated AND corruption has occurred on the source disk, the corruption WILL be copied (automatically) to the second disk. The admin needs "time" to discover that the source disk is dying and to stop the copy operation before data corruption is coped to the backup. This is why a daily Rsync copy operation is NOT recommended. If the job is automated, the interval should be set to a week or more. Users should consider running it manually, after significant data is added to the source disk and a cursory check is done to insure shares are still alive.

In the bottom line:
Nearly anyone can restore an Rsync drive-to-drive backup. While Rsnapshot is superior, with versioned backup that's fully automated and safe, it asks a lot of beginners and even intermediate users when it comes to restoration. (At a time when they're uncertain and may make mistakes.) Further, I don't think a document in the answer to that. There are so many variables and considerations involved that it would be difficult to adequately explain, and very lengthy, in a beginner's walk-through type doc.
________________________________________________________

Off topic but:
I'm looking at Python programming now, like at the very beginning.  
I'm thinking that a plug-in for Rsycn drive-to-drive backup might be a good project where convenience features could be implemented. As an example, the existing data drive could be populated automatically, the destination drive would be selectable, there could be the ease of scheduling in a GUI, etc., and auto-disabling the Rsync job, with e-mail notification, if SMART errors are detected on the source disk. The possibility for a one button, "Switch to Backup Drive" might also be possible.

But, something like that would be at least a year or much more into the future, if ever at all.

Zitat von crashtest

...auto-disabling the Rsync job, with e-mail notification, if SMART errors are detected on the source disk. The possibility for a one button, "Switch to Backup Drive" might also be possible.

Would that eliminate the need for SnapRaid? Where’s your PayPal donate button?

SnapRaid is something else altogether. It protects multiple drives, with a single drive, AND it provides for bitrot protection. Using a single disk to provide all of SnapRaid's features is a really impressive accomplishment.

Rsycn is just a simple backup solution that happens to be far better than RAID1. It could be made to check for bitrot, with checksums, but the speed of replication would be seriously impacted.

Zitat von crashtest

It protects multiple drives, with a single drive,

I know this is off-topic, but you started it 😉. But does it provide a true backup in the same sense as Rsync? I have read the SnapRaid documentation and SnapRaid info on this forum a number of times and I still cannot get my head around a parity disk “protecting” four data disks. I’m not saying it doesn’t, I just can’t visualize it. Just for fun I have repointed shares to a Rsync’d mirrored disk as described in the Startup Guide, and it just works. I can visualize that. Other than the bit-rot protection is there any advantage to SnapRaid if you only have one half-full data disk, and one of the shares on it is AppData which isn’t even included under the SnapRaid parity disk? You do need a mirrored backup to protect those shares not under the parity disk. I ramble. Sorry.

Zitat von Agricola

Just for fun I have repointed shares to a Rsync’d mirrored disk as described in the Startup Guide, and it just works.

That was the reasoning behind suggesting the method to beginners. (It just works.) Some experienced users use the same method as well.

Zitat von Agricola

But does it provide a true backup in the same sense as Rsync?

While SnapRaid provides a method for restoring a dead or failing disk and it can restore deleted files or folders as of the last sync, no, SnapRaid is not backup. While I believe SnapRaid is better than traditional RAID 5, the parity disk itself doesn't provide backup. The way I define backup is, a full, separate and independent copy of all data.

SnapRaid reconstructs a disk using the remaining disks in the array and parity data, from the parity drive, to reconstruct a missing (or dead) disk, in a manner very similar to RAID5. The key is, the reconstructed disk is in the condition it was in during the last sync operation when parity was last calculated. With RAID5, where parity data is calculated on the fly, the reconstructed disk would be current. (That is, if the resilvering operation succeeds.)
_____________________________________________________________________________________________

An Rsync'ed disk can be removed from the host, added to another host, and all data would be on the disk as it existed on the source disk. An Rsync'ed copy is a full, separate and independent copy of all data originally on the source disk.

Zitat von Agricola

is there any advantage to SnapRaid if you only have one half-full data disk

No. While SnapRaid can be used with two disks (parity becomes data) that's an odd-ball setup. To recover, a new disk would still be required.
SnapRaid is more useful as a method of protecting (and reconstructing if needed) multiple independent disks, or disks in (for example) a mergerfs array. SnapRaid is also useful for those who are looking for bitrot protect but do not want to invest 50% of their disk space toward the effort (such as the case with ZFS mirrors).

If you can fit all of your data onto a single disk, or if a single destination disk is large enough to house the contents of a source disk array, Rsync can create real backup.

Rsync will also synchronize array mount points, between various array types, but things can get tricky. Setup and thorough testing would be highly advised - users would be on their own.

Zitat von crashtest

If you can fit all of your data onto a single disk, or if a single destination disk is large enough to house the contents of a source disk array, Rsync can create real backup.

Alas, but no protection against bit-rot.