Beiträge von Adoby

In addition rsync allows you to efficiently have several versioned snapshot style hard linked backup copies. Each snapshot looks like a full copy, but (almost) only takes up storage needed to store new or modified files since the previous snapshot. Even if you have RAID, you still need backups to handle user errors and mistakes deleting or overwriting data. And if you have good versioned backups, chances are that you don't really need RAID.

For commercial settings RAID may be needed, in addition to backups, to provide high availability. But then I somehow doubt any SBCs and USB3 connected HDDs are used.

However, rsync backups/clones are not enough, in themselves, to provide bitrot protection. Then further measures are needed. Checksums and so on. This may be relevant for long term storage or archival of valuable assets. Some filesystems with redundancy are able to provide bitrot protection.

This:

"Detailing the reason on 'why USB is generally bad for this USB3-HW-RAID enclosure' would be greatly appreciated."

I think you are confused. I doubt anybody says that USB3 to a HW RAID enclosure is a problem? I have a 4 bay HW RAID enclosure connected to a RPi, myself. Currently not using any RAID, but still...

What can indeed be a problem is using USB for software RAID.

There are several reasons:

1. Several drives will share a USB connection, making for poor and/or unpredictable results.

2. It is likely that there is a mix of lose USB cables, USB hubs, enclosures and power supplies involved. All with one or two connectors that may be bumped by mistake or simply be faulty.

3. Users wanting to use USB with software RAID often are novice RPi users with little or no experience and knowledge of Linux and RAID. Needing a lot of help and having difficulties following/understanding written instructions. Not because they are stupid, they just lack experience and knowledge. In combination with point 2 this makes software RAID a really bad idea for them and it is extremely difficult to support. It may even be dangerous and cause data loss, because it is easy to setup software RAID using a GUI, but when something bad happens you may quickly need a spare unused HDD and use the command line...

Are you possibly using a NTFS formatted filesystem with OMV?

I would strongly advice against that...

A temporary fix, until you find a real fix, might be to rename the folders to not use accented characters?

I am a little "old school". I never use accented characters or spaces in folder and file names. Only a-z, A-Z, _.- and 0-9. A bit silly, perhaps. But it saves me a lot of headache.

You just go into the correct folder in the destination directory and copy the file(s) you need from there.

My preferred way of handling IP addresses in my home LAN is to do it on a combined Dnsasque and DHCP server. Many modern home routers combine DHCP with Dnsmasque. I use a separate small Gl-Inet router for this, specifically as a DHCP and Dnsmasque server.

This allows you to permanently map server MAC addresses not only to an IP but also to a local host name. And you get a central point for administration and and backup of the LAN. If I install a new OS on a server, it automatically has the same IP and host name, without me having to do anything on the server. Nice!

Yes, it is possible. Should work perfectly fine as long as you only want basic NAS functionality. Having only 2 GB may prevent you from doing more demanding and interesting stuff. But 2GB should be plenty for the basic stuff.

You might want to think of this NAS as a way to learn and get more experience. Later you may want to upgrade to something bigger and better or something smaller and more power efficient. And something that is powerful enough to run several dockers for streaming, downloads and other stuff.

I would recommend that you buy bigger HDDs. Bigger than you need now. Otherwise you are likely to want to upgrade soon. And good HDDs can last for many years. The warranty is 2-5 years and many HDDs last way longer than that. When/if you upgrade sometime in the future you can use these HDDs in the new NAS, making the future upgrade cheaper.

Or try to get some old used 1TB HDDs from someone that has upgraded to bigger HDDs. Buying a new 1TB drive today, when there are 18TB drives for sale, and 8TB SSDs, seems backwards. I suspect there are plenty of cheap used 1TB drives available, if you can find them.

You can also login directly on the OMV NAS using SSH and then create folders as you please and where you please using normal Linux commands and tools. Bash. In effect opening up the hood and directly messing with the internals. NOTE: Unprotected access...

I often use mc (Midnight Commander) for this purpose.

Typically you just want to create and rearrange sub folders in existing shared folders, or move files around. It is very easy to mess things up and make OMV unusable and possibly cause data loss. But if you do know what you are doing this is a VERY powerful and fast way to manage your files.

Using mc on a Linux computer it is even possible to open up a remote pane on the OMV NAS over the network using the FISH protocol. Great for quickly copying files or editing scripts and so on.

If you have to ask about this you most likely don't know enough to use it safely. And you are better off managing the shares and the contents from a client over SMB or NFS.

Of course it is possible to fix. But it is a proper mess to get right.

When I messed up as you have done, I just did a fresh reinstall. And got it right, without any errors or mistakes at all. But it took a few tries.

Then I cloned the root filesystem. So I wouldn't have to do it again...

Unless you have done something strange, I suspect that you should use the export folders instead of the shared folders directly. At least that is what I do.

In other words, try:

umount -f /mnt/movies
mount -t nfs 192.168.2.30:/export/Media2_bis /mnt/movies

Assuming Media2_bis is the name of the shared folder and it is shared using NFS.

It is a RPi4. Just remove and reformat the SD card and no more OMV.

Flash whatever OS you prefer to the card and carry on.

I am WikiBox on GitHub.

https://github.com/WikiBox

I suspect you are doing something very, very wrong, but you don't tell us enough details about what you are doing, so it is difficult to help.

Sorry.

It seems you have a lot of errors, and that makes it impossible for you to apply changes? Fix that first. Tidy up. Make sure there are NO ERRORS. Then try again, and do it right, whatever it is you are trying to do.

It is possible that the problem is not the new drive but some other drive that is no longer available.

You may need to tidy up. If you have other devices that are not available, remove all references to them in the GUI, along with all shared folders and services that use them.

Once you only have the filesystems and shares you actually use, at this moment, reboot and try to mount the filesystem again.

Using snapraid you will only be able to restore files you have the parity off. So files added or modifications since a recent sync will be lost. Unless you have a backup copy...

As far as I know there is, currently, no tool as you describe it. There are backup tools with checksums that can be used to detect errors in backup sets, but not to fix them.

I am writing, as a "hobby project", a very simple command line backup tool, "bitback", for local snapshot style backups with file level deduplication and file hashes. It can also scan for, detect and automatically fix bit rot in both directions, to/from the most recent backup copy. No idea when it will be released. Perhaps this year...

The idea is to run bitback daily to backup and hash new or modified files in a timestamped full snapshot of the source filesystem. At the same time a certain percentage of the old files in both the source and the backup filesystems are "scrubbed" and checked for bitrot, and corrected if possible. For performance reasons (read speed during re-hash) the filesystems should be on different drives on the same computer, unless you have 10GbE or don't mind waiting and congestion on the network.

With one parity drive you can recover from one full drive failure.

With two parity drives you can recover from two full drive failures.

...and so on.

A parity drive only stores the parity for a set of drives, not the full information for all drives in the set.

https://en.wikipedia.org/wiki/Parity_bit

Zitat von henfri

And it is the first time I hear the claim that Flash is more robust against writes than a HDD...

I have also never heard that flash is more robust against writes than a HDD.

Where did you hear that?

Many docker apps store frequently variable data and metadata. Perhaps in a database. This may lead to random writes. Examples are torrent download clients or media managers with frequently updated metadata.

Zitat von insanitie

I have a spare Crucial MX100 2.5 500 Gig SSD.

Should i keep as intended installing OMV onto 64GB Flash, and then have the 500Gb SSD where i install the docker and all Docker stacks?

That is how I would do it. The rootfs on a USB thumb drive and the flash memory plugin installed. And everything docker on a SSD. Media files on spinning disks.

Yes, you will be able to add and access the data drives after a reinstall.

Just to be on the safe side, it might be a good good idea to disconnect the data drives before you reinstall. Then, when OMV is up an running fine, reconnect and add the drives. And you should be able to mount the filesystems and recreate shares and so on.

Then, clone the rootfs...