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

  • How do I replace a disk that is NOT in a RAID?


    I have a disk that is throwing SMART errors and I want to replace it.


    First, how do I copy the current contents to another mounted drive that is currently not in use?
    Second, how do I unmount the failing disk? In 'Storage' I have 'Physical Disks', 'S.M.A.R.T.', 'RAID Management', and 'File Systems', but in 'File Systems, 'Unmount' is inactive (grey).
    Third, how do I tell Plex Media Server where the files are?


    Many thanks.


    (Also, how do I find my OMV Version?? I am just guessing to post the questions.)

  • 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.

  • How do I replace a disk that is NOT in a RAID?

    I have a disk that is throwing SMART errors and I want to replace it.

    First, how do I copy the current contents to another mounted drive that is currently not in use?
    Second, how do I unmount the failing disk? In 'Storage' I have 'Physical Disks', 'S.M.A.R.T.', 'RAID Management', and 'File Systems', but in 'File Systems, 'Unmount' is inactive (grey).
    Third, how do I tell Plex Media Server where the files are?

    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!

  • simply.


    save all data that can be posible on the new disk or other place, and delete all the shares on failing disk, so finally you can detach from webGUI, atach the new disk and recopy data ( or share data if are previosly copied on it).

  • 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.

    Air Conditioners are a lot like PC's... They work great until you open Windows.


  • There also is a way without deleting old sharedfolders and their references to any services using terminal/ssh. Just mount the new drive, rsync all data from the old to the new one using e.g.

    > rsync -aAP /srv/_OLDDRIVE_/sharedfolderX /srv/_NEWDRIVE_


    Then the location of each sharedfolder can be changed in the OMV GUI. A warning is displayed that the data must be copied manually (done). After that the old drive can be removed.


    EDIT: Sorry I did not notice this thread is about omv 0.2. This way is only tested with omv 4 and 5.

  • EDIT: Sorry I did not notice this thread is about omv 0.2. This way is only tested with omv 4 and 5.

    Truth be told, neither did I. I built my NAS a month or so back using OMV 5.


    I did get things moved over but, I stumbled through it a bit. Fortunately the drive that started to fail was one I used for backing up connected pc's and storing software downloads. If I lost the content I could have run new backups of the connected pc's and download other missing content.

    I'll chock this up to a good live fire drill or practice run. In the event that one of the other drives with more critical content fails I have at least worked through this once.


    Thanks All for the feedback and advice!

  • 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.

    Simple and sure backup and restore: In a Scheduled Job: rsync -av --delete /srv/dev-disk-by-label-SOURCE/ /srv/dev-disk-by-label-DESTINATION/ (HT: Getting Started with OMV5)
    OMV 5 (current) - Hardware: Thinkserver TS140, Nextcloud, Plex, Airsonic, Navidrome, Ubooquity, Digikam, & Heimdall - NanoPi M4 (v.1), backup - Odroid XU4, Pi-Hole (DietPi) - Testing/Playing: hc2, xu4, Pi 3B+, Odroid H2. Mac user trying to convert to Linux on a HP dx2400, Debian 10 XFCE.

  • The information above is really good and comprehensive and has triggered a question in my mind regarding my setup.


    I have got two 4TB data drives in my Helios4 setup running OMV5. The first drive is my active drive which has got SMB/CIFS shares giving access to two shared folders I have setup.

    The second drive is my backup drive. I am running backups using the OMV RSnapshot plugin, which I understand is built on RSync.


    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?


    Would it be better to wipe the backup drive and start again with RSync backups as per the OMV5 guide?

    Thanks :)

  • 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. =O 
    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. ;)

  • ...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?

    Simple and sure backup and restore: In a Scheduled Job: rsync -av --delete /srv/dev-disk-by-label-SOURCE/ /srv/dev-disk-by-label-DESTINATION/ (HT: Getting Started with OMV5)
    OMV 5 (current) - Hardware: Thinkserver TS140, Nextcloud, Plex, Airsonic, Navidrome, Ubooquity, Digikam, & Heimdall - NanoPi M4 (v.1), backup - Odroid XU4, Pi-Hole (DietPi) - Testing/Playing: hc2, xu4, Pi 3B+, Odroid H2. Mac user trying to convert to Linux on a HP dx2400, Debian 10 XFCE.

  • 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.

  • 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.

    Simple and sure backup and restore: In a Scheduled Job: rsync -av --delete /srv/dev-disk-by-label-SOURCE/ /srv/dev-disk-by-label-DESTINATION/ (HT: Getting Started with OMV5)
    OMV 5 (current) - Hardware: Thinkserver TS140, Nextcloud, Plex, Airsonic, Navidrome, Ubooquity, Digikam, & Heimdall - NanoPi M4 (v.1), backup - Odroid XU4, Pi-Hole (DietPi) - Testing/Playing: hc2, xu4, Pi 3B+, Odroid H2. Mac user trying to convert to Linux on a HP dx2400, Debian 10 XFCE.

  • 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.


    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.

    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.

  • 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.

    Simple and sure backup and restore: In a Scheduled Job: rsync -av --delete /srv/dev-disk-by-label-SOURCE/ /srv/dev-disk-by-label-DESTINATION/ (HT: Getting Started with OMV5)
    OMV 5 (current) - Hardware: Thinkserver TS140, Nextcloud, Plex, Airsonic, Navidrome, Ubooquity, Digikam, & Heimdall - NanoPi M4 (v.1), backup - Odroid XU4, Pi-Hole (DietPi) - Testing/Playing: hc2, xu4, Pi 3B+, Odroid H2. Mac user trying to convert to Linux on a HP dx2400, Debian 10 XFCE.

  • 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.

    Thank you very much for your reply! There's a lot of detail to process in your response, but I think the take home message for me is - Yes, RSnapshot has the benefits of versioning etc. This benefit has the side effect of making restoration more complex. Do I know how to go about that process at my current understanding level with OMV? No, is the short answer.


    As you so aptly put, if a backup can't be restored easily and within the abilities of the user, then the backup is useless.


    I really appreciate your advice :). I'll be wiping my backup disk and completing backups with RSync; starting with the process outlined in the OMV5 Guide.

    Thanks!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!