Beiträge von Adoby

So I have plenty of storage and good versioned backups. Now I can worry about bitrot. Maybe?

Very rare random errors creeping into the data over time. Very rare, but increasing the storage increase the probability of random errors.

I use versioned backups on the folder level using rsync snapshots over the local network.

Ideally I would like a system with checksums on a file level. That can be used to find files with bitrot. If the checksum has changed but the modification time has not changed, then we have bitrot. If bitrot is detected then the file is restored from backup. Perhaps with an extra check of checksum on the backup copy and optionally use an older, error free, copy of the file if available.

So I would have to quickly create new checksums and update snapshots often. Otherwise bitrot errors may migrate into the backups.

This seems like something that might already exist? It could be integrated into a rsync backup system. Rsync use checksums and copy files back and forth. And rsync knows where the copies of the file are. It would be pretty lightweight, except for all the checksum calculations, and need very little extra storage. Just a database for the filenames, checksums and file modification times.

Does anyone know if something like this already exists? Or something better and even simpler?

I have considered btrfs for bitrot protection, but without some form of redundancy, raid 1 for instance, I don't believe btrfs can protect against bitrot, only detect it. Then you would have to manually restore from backups?

Otherwise I second ext4 and versioned snapshots to other media using rsync. But I worry about bitrot...

I have a very different setup, but somewhat similar topology... Note that OMV is a full Linux system. You are not limited to the functionality of OMV but can use the full functionality of Linux. OMV provides some of this functionality, but not all.

I have a bunch of small SBC servers running OMV. Odroid HC2s. Two SBCs are used for media storage and backups of my laptop and my PC, nas1 and nas2. They each have a shared folder on a 12TB HDD. Two other SBCs are used for are used for backups, nas3 and nas4. They each have a shared folder on a 8TB HDD.

The shares are all configured and managed in OMV. I use NFS4 and EXT4. And SMB for Android clients.

I use autofs in Linux to automatically have each server mount the other servers over NFS4.

I use cron, configured outside OMV, to run daily backup scripts on nas3 and nas4 to create versioned rsync "snapshots" of important folders on nas1 and nas2. I typically keep one snapshot per day for a week, one snapshot per week for two months and one snapshot per month for a year. 7-8-12. My backup scripts work very similar to rsnapshot, but are just small bash-scripts, with different settings for snapshots of different folders.

By using autofs I can allow the HDDs on the SBCs to spin down when they are not used. Saves power and makes the SBCs run cool. When it is time for backups or other access the HDDs automatically spin up and autofs mounts the shares again, as needed.

Note that autofs is a bit old. There are new methods using x-systemd.automount that may be better. And x-systemd.automount might be possible to implement from inside OMV. Perhaps. I use autofs instead because I have been using it for a long time and know how to make it work, and it is configured completely out of sight from OMV.

This is a very simple and basic setup, but it works fine.

The kernel in the OMV version you install may not support the APU. It is common that kernels in Linux lag behind new hardware a few months.

Try to install using SSH as if your computer is headless. Then update at once and reboot. I don't know if an update will update the kernel, but it might be worth a try. Eventually it will. If this was the issue.

Login as root over SSH is disabled by default. Not safe. Enable it (Services, SSH) or (better) use sudo.

System backup: Clone USB thumb drive with OMV system to a spare USB thumb drive and to image stored on HDD.

Scenario: USB thumb drive catastrophic failure.

Corrective measure: Replace USB thumb drive with backup thumb drive. Reboot. Carry on.

Maintenance: Clone the OMV system USB thumb drive after major upgrades and reconfiguration. Also clone the thumb drive image to secondary backup on HDD.

For some/normal/small/old HDDs Linux use 10 bytes to keep track of stuff on the HDD. For very big HDDs Linux can shift over to using 16 bytes instead. That is "READ CAPACITY(16)".

And everything works fine!

Now you know!

Make sure you don't mix up bits and bytes. 1 byte = 8 bits. Bits = b, Bytes = B.

12 Gb (gigabits) is not very far from 1.2 GB (gigabytes).

Either offline booting from other media or unmounting sdb in OMV. If it was metal I would boot from other media.

You can't resize the partition while it is mounted.

I agree, 8 GB should be fine. More RAM means bigger HDD caches, so it is not wasted at all. My SBCs run fine with 2 GB.

By default OMV tries to make you use one whole drive for the system. I run OMV from SD cards on my SBC servers. Works fine.

One possibility:

Get a cheap SSD and put the root file system on it. 20-30 GB should be plenty. When you have OMV running fine, including shares but not extra apps like Plex (I prefer Emby), add a partition that use the rest of the SSD.

Use the extra partition for backups of the rootfs (you'll need remote backups as well) and use it for big apps and data. Put Plex (or Emby) there, and other apps and data. Including docker images when you have learned more.

Plain OMV runs fine on quite modest hardware. I run OMV on tiny Odroid HC2 SBCs with the rootfs on SD cards and during sustained file transfers they can easily saturate a GbE connection. The bottleneck typically isn't the drives or the CPU, it's the network. And that makes my servers fast enough for me. It might be a different story if I had to transcode a lot.

Bara dra ut sladden!

Most likely some service is using the SSD.

Depending on what you are doing it might make sense to shut down and boot from other media or move the SSD to another computer.

No, a big SSD makes no sense for OMV. Most (all?) of OMV is cached/stored in RAM when you run it. If you by OMV means only a NAS with file-sharing functionality. Plenty of RAM would be better to improve disk caching.

But you can use OMV for other tasks, as an application server, then an SSD might make a lot of sense. Use the SSD to store caches of metadata and databases and docker images and VMs.

I think that my next SBC will have a very fast NVMe SSD that is used to cache NFS and HDD access. But I don't think it will be for at least a year. I doubt I will run OMV on it, but it will access my small group of Odroid HC2s with OMV.

MC should work fine. You are doing something wrong. Impressed!

Otherwise try

rsync -a source destination

Do one folder at a time.

One possibility is that the UUID/PUUID for the partition/disk changed when you resized. Worth checking.

If that is case, as far as OMV is concerned you removed a HDD and replaced it with a completely different HDD with a different size.

Work around is either to edit OMV configuration files and change UUID there or to remove the data HDD from the OMV GUI before you resize and add again, with the new UUID, after.

You update/reflash the SATA firmware and specify the new spindown time then. If you set spindown to 0 it is disabled.

Also note that some harddrives have problems with hdparm. If you set ANY of the physical disk properties in OMV, then hdparm tries to set them and disks may fail to mount. Or even unmount spontaneously. Some drives are fine. Your drive seems to be in between. Works mostly but ignore change spindown settings.

I recommend that you disable all of the physical disk properties. Just to be safe and to avoid that hdparm tries to change settings on your HDD, and possibly fail.

I have set my HDDs to spindown after 30 minutes. I don't think spindown/spinup cause any harm to my HDDs. But it may be that bad hdparm settings and/or old SATA firmware in combination with some HDDs spindown noisily and age prematurely according to SMART. After I flashed SATA firmware and disabled any settings in physical disk properties this problem went away. Now my HDDs spin down fine and reduce power needed and runs cooler.

https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

Please note: It is possible that the SATA is already updated, then there is no point in updating it again unless you want to change the spin down time from the default. Then just make sure to not touch the physical disk properties at all. The default spin down is a couple of minutes, I believe.

If you still want to flash the SATA, or just want to check if the version of the firmware really is the latest:

Get a thumbdrive and a SD card reader. (Or use a PC/Laptop with a SD card reader.)

Then install some version of Linux on the thumbdrive and boot from that and use this and the SD card reader in a PC to copy over the SATA upgrade tools to the SD card.

You will need this anyway to be able to make a backup of the SD card when you got everything running.

I either use a HP Laptop with a built-in SD card reader, with Ubuntu 18.04, or copy files over the network from another OMV NAS or another Linux computer. I also created an "updater SD card" with Armbian. I put firmware updates on that and insert it in one HC2 after another, boot and update over SSH. That was how I updated SATA and spin down on my Odroid HC2s. I kept the card for future updates or for when/if I get more HC2s..

There has been cases where the spin down doesn't work correctly. Then the spin down may have caused the HDD to age prematurely. But this is not the case if you update SATA and set the spin down there. I have my spin down set to 30 minutes. It makes the HC2s more quiet and they run cooler. And I believe it is beneficial for the life of the HDD, or at least not at all harmful.

See this thread, it might help:

Odroid HC2 8TB WD red too big?

TL;DR

Don't touch/disable any changes to the physical disk properties. Update SATA and set spindown there. Reinstall from scratch if the installation still is corrupt after that.

Most likely that should work fine.

Just try it. Install everything you need from the command line. I don't see any obvious reasons why it should not work. No need to install as a plugin to OMV, just run it parallel to OMV.

But just to avoid extra work, make sure you backup the root filesystem first.

I suspect that the problem for the OP was that the Linux kernel didn't correctly identify the APU, and because of that couldn't use the correct graphics driver.

If it is possible to set the graphics in the APU/motherboard combo to emulate a plain old VGA-card, then I assume that everything should work. Or if a newer kernel is used, that can recognize the new APU/motherboard combo.