Posts by Nibb31

    So if I format the external drive to ext4, I would be able to save my win 7 files to this new file type, and download them back to the NTFS system without any issues? Thx.

    Windows doesn't care about the filesystem. It doesn't see it, because the drive will never be attached to the Windows PC. The Windows PC never reads or writes to the disk. The RPi does.

    The drive is attached to the RPi, which runs OMV, which is Linux. The Windows PC only sees the actual files served by the RPi over the network, not the underlying filesystem.

    If you leave the storage plugged into the RPi, which is a Linux machine, you need to format it with a Linux filesystem. The Windows machine is never going to access the drive directly. The RPi will be doing the reading and writing to and from the drive and will serve the files to the Windows machine over the network.
    So you probably want to choose ext4.

    I don't see why not. There are several paths:
    - OMV is Debian. There is nothing preventing you from installing Wordpress and NextCloud on the same OS. However, there could be conflicts.
    - OMV has a VirtualBox plugin for running VMs. You could install OMV on the bare metal, and then run VMs for your other apps.
    - OMV has a Docker plugin. You could install OMV on the bare metal and run your other apps in docker containers.
    - You could install a hypervisor (Proxmox, ESXI, etc...) on the bare metal and run OMV, Wordpress, and Nextcloud in their own VMs.

    It's easier to install OMV on top of a desktop OS rather than to install a desktop environment on top of OMV. To do this, you would install a standard Debian (or Raspbian) and then install OMV from the command line, not the ISO.

    However, there is a remote desktop plugin for OMV, which installs XFCE and remote desktop server on top of a standard OMV setup. This would allow you to log in graphically with Remote Desktop client a use GUI tools

    Compression efficiency depends on the type of data. Media content is usually highly compressed already, so you won't gain anything by running it through another compression mechanism. Plain text files, raw bitmaps, uncompressed wav files are the sort of data that benefit from compression.

    RAID is for high availability, not for backup. It allows users to keep on working, and rebuild the array, after a drive failure.

    It is not a backup because it doesn't protect your data from: user error, malware/viruses, file corruption, power surges, hardware failures (other than individual drives), OS failures, fire, flooding, theft, etc...

    Also, during the rebuild, your data is at risk of a second drive failure and then you lose data.

    So RAID is not backup. Backup is a second set of your data, preferably on another device, preferably off-site, preferably with periodicity, but absolutely not in real-time sync with the primary set of data.

    Rsync is NOT complicated. It's just a command that copies files from one location to another. You specify the source folder and the destination folder. There is an rsync plugin in OMV that allows you to set up an automatic rsync job on a periodic basis.

    I don't believe we'll ever see stable btrfs RAID-5/6 at this point. I'm not willing to commit to it now and cross my fingers that it will arrive next year or in 5 years or never.

    I also don't want to go without any redundancy at all, so a btrfs JBOD with no redundancy, as you suggest, is out. And I don't want to "waste" 50% of my disk space on replication like RAID1 or a full 9TB rsync backup. Remember, this is a home media server on a budget.

    Really, a 4-drive RAID5 is the sweet spot of data/parity ratio that I'm after for this application. I'm just wondering if there is a better option out there than the ext4+SnapRAID+mergerfs combination that I currently use.

    What do you think of mdadm RAID5 with a btrfs filesystem on top ? I think this is what Synology uses.

    Ok, I think I might have figured a way to do the migration without investing in an extra 8TB of storage (yeah, I'm cheap, and $200 is more than I want to spend on this data).

    Right now I have:
    3TB DATA1
    3TB DATA2
    2TB DATA3

    Let's say I buy a 4TB drive to replace the 2TB. I also have a spare 1TB drive sitting around. This is the plan:
    1) Copy DATA1 and DATA2 to the new 4TB, the 1TB spare and what's left on the 2TB. This should cover it.
    2) Wipe DATA1, DATA2, and PARITY.
    3) Create a degraded ZFS RAIDZ1 using 3 drives (is this possible ?)
    4) Copy the backup drives to the RAIDZ1
    5) Wipe the 4TB, add it to the RAIDZ1 (using only 3TB but future proofing), and resilver.

    This plan relies on the possibility of creating a degraded RAIDZ1. Would this work ?

    other bad thing is that your desired config: Data(3TB + 3TB + 2TB) + Parity (3TB) is artificially reduced to 2TB+2TB+2TB=6TB of usable data, because you have only one 2TB disk in the Zpool.

    Yes, I am planning to replace the 2TB (which is my oldest drive) with a 3TB.

    The valuable data (about 1TB) certainly is backed up. It's the media data that isn't. As I said, it would be a pain to lose it, but it isn't valuable enough to justify spending several hundred euros on a backup solution.

    Not a great idea especially with older disks in Linux/OMV. Once a disk in your array dies you have zero redundancy any more. Replacing the drive the following resilvering will take ages since ZFS on Linux does not implement 'sequential resilver' but does this in a fashion that could be best described as 'worst case random IO scenario' possible. So when your fist disk died of age please be prepared that most probably another one will follow soon as a direct result of the resilvering stress...

    Isn't this true for any kind of RAID 1 or 5 ? Since my hardware only has 4 bays, I won't be using RAID6. This is a home server on a budget and I can't afford to "waste" 50% of my drive capacity.

    Also, the drives are various ages (1 to 4 years) and various brands (Toshiba, WD Green and Blue), which limits the risk of them having the same MTBF.

    My current setup is an HP Microserver Gen7 home server with 4 bays running ext4+SnapRAID+mergerFS in the following configuration:
    Data(3TB + 3TB + 2TB) + Parity (3TB)

    I have no way to backup the 7TB of data. These are mostly media files that I would rather not lose, but aren't valuable enough to justify another 8TB array for backup.

    The drives are 80% full and I'd like to upgrade the 2TB to 3TB and at the same time convert to ZFS (4x3TB in RaidZ1) without losing data.

    This is how I plan to do this:
    1) Wipe the Parity drive and format to ZFS Raid0.
    2) Copy contents of Data1 to new ZFS1.
    3) Wipe Data1 and format to ZFS Raid0.
    4) Copy contents of Data2 to new ZFS2.
    5) Wipe Data2 and format to ZFS Raid0
    6) Copy contents of Data3 to new ZFS3.
    5) Wipe Data3 and format to ZFS Raid0
    6) Format new drive to ZFS Raid0
    7) Finally create new zpool with all 4 ZFS drives

    Is this the correct way to do the migration ? Is there a better way ?

    You can't use the system partition to hold shared folders in OMV.

    If you want to do that you need to repartition your drive with Gparted or similar:
    - Boot into Gparted
    - Resize system partition down to something like 16GB (should be more than enough)
    - Create another ext4 partition with the freed space.
    - Reboot in OMV and the new partition should be available for your data.

    Still, with 2 RAID1 arrays, you are wasting half of your drives for no reason. If you want the drives to be readable outside of the array, you could go with SnapRAID and mergerfs. This would only waste 1 drive.