Beiträge von Adoby

You might reconsider how you use OMV. It is possible to install OMV to a thumbdrive and run it from there. Then you can backup your rootfs simply by backing up the thumbdrive. Google "image thumbdrive".

However, if you use OMV for other purposes than a simple NAS, then it may not be a good idea to run OMV from a thumbdrive.

Then, if you have OMV installed on a HDD or SSD, you can boot from some other media and backup OMV that way. You might use Clonezilla for instance. Or SystemRescue. Or any version of Linux with suitable backup or imaging tools. For instance rsync and dd.

https://clonezilla.org/
http://www.system-rescue-cd.org/

You boot from other media because it can be hard to reliably backup a running Linux root filesystem.

Google "backup root filesystem" for other techniques and tutorials.

I myself run several OMV servers from SD-cards. I just use OMV for the NAS functionality. I wrote a couple of scripts to backup and restore the SD-cards. Similar to imaging a USB drive.

On my Linux computers I dual boot to two separate Linux systems. One main and one small I only use to backup the main system, using only rsync. I store the rootfs backups on my OMV NAS servers.

Check the specs. The GS316 is max 8.4 W. I doubt a 24 port draws more than double that.

But they may have internal PSU. That may be good or bad depending on what other equipment you have and how you power it.

Some switches has smart power draw depending on the ports actually active and also on cable length. I use mostly 25 cm cables...

They all look fine.

I went with a Netgear GS316. 16 ports means less power. I even considered 8 ports for that reason.

Also I considered voltage. I use my GS316 for a group of Odroid HC2, an Asus Lyra Mesh unit and a Noctua fan. Everything is run by 12 volt so I can run all these devices from one single fanless PSU.

I use a 3 node Asus Lyra Wi-Fi mesh for clients. The switch is to connect the HC2s to each other and to the Wi-Fi mesh. Each Lyra node has 2 ports so I get 4 extra remote ports with decent speed that way.

If you wipe the data drives when you reinstall, or store data in the root filesystem, then yes. The data really will be lost when you reinstall. But you don't have to wipe the data drives. Use them as they are. Then all the data on the data drives remain there, unchanged by the reinstall. I suppose that this is why OMV by default has a separate drive for the root filesystem.

Please also note that if you consider your data important, you demonstrate that by making sure you keep several good backups of it. And make sure that you know how to restore the backups. Otherwise you obviously only have yourself to blame if any data is lost. Data that is not backed up at least three times is obviously not very important.

There are NO guarantees that your data is safe from you. If you erase the data it is gone, even if you did it by mistake. Unless you have backups.

It might be possible to manually extract individual files with settings from a bad OMV install, and reuse them in a new install. Or to fix a bad OMV install without reinstalling. But how do you know what settings are good and what settings are bad or even corrupt and might cause problems? I don't know. So I reinstall or restore a backup.

The whole point of reinstalling is to make sure everything is fine. And when it is you make sure to backup the working root filesystem. That way you can make sure the settings you save are correct.

When I reinstall I disconnect the data drives. And only reconnect them when OMV is running fine and has been updated fully. That is to protect the data from mistakes I might do while reinstalling and updating.

When I first started using OMV I reinstalled many times. But I learned and started to backup the root filesystem. Then if there are ANY problems I can restore the root filesystem and quickly be back to a perfect OMV install again. With all settings correct. And I also backup all my important data. Some of it more than three times. Some only once.

Zitat von micka260

... it is installed at the root of the hard drive and it is totally dedicated to the system.

That is the rootfs. Where the OMV and the operating system is.

You have other filesystems on other drives, but they are all mounted somewhere in the root filesystem. For instance in /srv

The root filesystem is where Linux, OMV and (all?) the settings reside.

OMV usually have a drive with the rootfs (and possibly boot) and one or several drives with the storage filesystem(s)

Make screenshots to document settings.

After you have made a reinstall, restore the settings from the screenshots.

Make sure to backup the rootfs BEFORE you do any changes or updates. If the changes/updates don't work out, restore the rootfs. If the changes/updates work out, update the rootfs backup. Otherwise you will have to reinstall and loose all settings soon again.

You can most likely clone the 64 GB SD card to the 16 GB SD card. The reason is that you most likely use less than 8 GB of the card. I can imagine that it might be difficult in Windows. So use Linux. You can install and run Linux from a thumbdrive. There are many rescue distros available that already have all the tools needed to clone drives and SD cards. You might have to get a SD card reader as well.

So get a thumbdrive and install Linux to that, and clone away using Linux tools. You MUST have this capability anyway. Otherwise you wouldn't be able to backup your rootfs. And that would be silly, wouldn't it?

A fan controller with a sensor?

Nothing exotic.

One HC2 with armbian as "ctrl" with a SSD that run Emby, LMS and some other automation software. Node-Red, mqqt broker. It serves media from nas1-nas2. Underutilized at the moment...

Two HC2 with OMV as nas1 and nas2 with 12 TB Ironwolf HDDs. The actual storage. Video, music, books and so on. Also storage for backup snapshots of clients. Also backup important folders from each other. Scripts are run from cron.

Two HC2 with OMV as nas3 and nas4 with 8 TB Archive SMR HDDs. Stores and creates versioned rsync snapshots of selected folders on nas1 and nas2. Scripts are run from cron.

Also an old Synology NAS with backups of all rootfs and important files. Usually turned off.

But no networked distributed fs. Just nfs4 and ext4. And all mount all the other using autofs. And all connected to the same GbE switch.

When I want to expand, in the future, may put a big HDD in ctrl and rename it to nas0. And get a newer SBC as new ctrl. And add nas5, nas6 and so on.

Since the 16-port switch has a 32Gbps internal bandwith the total theoretical bandwidth between the SBCs will increase for quite a while if I add more SBCs.

My setup is a little like a pyramid. Access via ctrl on the top. Then storage for ctrl below on the next tier on nas1 and nas2. Then below that nas3, nas4 and the old Synology 411j for backups of the tiers above. But even if it can be seen as three levels everything is accessible from everywhere.

I miss the ability to cache nfs in ctrl. But that will be available next kernel release for armbian. Also SBCs with SATA and NVMe would have been nice to cache the spinning HDD and nfs on a NVMe SSD. But I suspect that will be old hat for high end SBCs soon.

I'm considering using some form of centralized script manager to launch scripts to run on the different nodes. But so far the added complexity of a new app outweighs the need to manage cron jobs and scripts on nas3 and nas4. But it might be fun with a central script/job manager...

What I got is extreme overkill for what I need. I like to fiddle and automate and this set up allows me to do that. And it all blinks very nice in my bookshelf. Especially at night...

Replace the video card and/or the monitor and/or the monitor cable.

Or:

Turn the monitor off and remove the keyboard. Do a headless install. Connect to OMV using SSH and finish the install that way. Use OMV headless over SSH in the future. Works fine. Make sure you keep up with the rootfs backups, you don't want to troubleshoot a headless server with network problems.

There are too many possibilities to list them. A brief start:

The install is bad.
Something shaked loose in the move.
Bad network cables.
You attempt to connect to the wrong device.
Cosmic radiation fried a few bits on the root filesystem.
You have an enemy that sabotage your stuff.

I think the most likely is that you attempt to connect to the wrong device. Or the enemy stuff.

When you install OMV to a USB stick you write an image of OMV to the stick. This is OMV. By writing the image to the stick you installed it on the stick. However it is not yet fully installed. When you boot from the USB stick the first time OMV will be fully installed. OMV may adjust partition sizes and reach out to the internet for upgrades. Again, this is the normal procedure to install OMV. Nothing special. Use at least a 16 GB USB stick or SD card to make sure that OMV can resize partitions OK. 8 GB might work.

I use Odroid HC2s and they work great. I upgraded from a Synology 411j. I still have the 411j but only use it for backups now.

I don't know anything about WDMyCloud, except that it sounds like something to avoid.

You need to write the OMV install image to the USB stick and instruct the PC to boot from USB. To avoid problems you may also want to disconnect all other drives before attempting to install OMV. When OMV is installed you can reconnect the drives and share their content using OMV. All this is the normal procedure when installing OMV. Except that you typically want to wipe the drives you will use as data drives.

Also note that the performance of OMV may be very disappointing if you use a windows native filesystem like NTFS and/or connect data drives via USB.

What filesystem are you using on the HDD and the thumb drive? If any is NTFS, FAT32 or exFAT (windows native filesystems), then try with EXT4 or some other Linux native filesystem. Seriously!

Also remember that the USB port in the HC1 is USB2, not USB3. Use it for removable backup media. Don't use it for a shared folder on a data drive. Get a bigger HDD instead.

Not sure what you are asking.

The major tools I use are rsync and Midnight Commander. Besides scrapers, renamers, organizers and taggers like TinyMediaManager and Picard MusikBrainz, calibre or Emby. Along with cron and some custom scripts for backups.

I'm a Linux user. So mostly I use NFS4. But for some Android devices also SMB/CIFS. FolderSync, SSH-helper and EZ FileManager are used in Android. Along with various apps for media consumption.

I have a multiroom speaker setup based on the venerable Logitech Media Server with original Squeezeboxes along with newer Volumio and PiCorePlayer clients.

I connect my 5 small SBCs to each other with NFS4 and autofs. Completely outside OMV. Also to an old Synology NAS used only for backups. Using NFS4 traffic between the boxes is fast and easily saturate a GbE connection in sustained transfers of big files. I have the SBCs on a book shelf, connected to the same GbE switch with 25 cm CAT6 cables. I have found autofs very reliable and stable, if a bit fiddly to set up. It allows the HDDs to spin down and up as needed and connections to drop or be reestablished between the boxes automatically.

The rest of the home network is over 5GHz WiFi using a 3-node Asus Lyra mesh along with a parallel 2.4GHz WiFi network over GL-AR150 boxes used for local IoT type connections. Internet is via a small openwrt GL-AR300 router configured to bridge between the 5GHz and the 2.4GHz WiFi and to share internet from my 4G phone over the network, when available.

Regarding rsync backup scripts.

I recommend that you write your own. Test it and make sure you understand what it does. And what it doesn't do. Then you can use that script again and again with confidence.

If you Google "rsync backup script" you get many hits. You can most likely find a good starting point that way. There are many wierd and wonderful backup scripts out there.

If you follow references and sources backwards you tend to end up at this very old site:

http://www.mikerubel.org/computers/rsync_snapshots/

There you can read about how early versions of rsync were improved to allow you to do rsync snapshots in a single command. That site was my starting point.

I have recently (around 6 months ago) added improved rotation of the old snapshots to my script. I used to simply keep 30 daily snapshots or purge manually now and then. Now it is based on promotions and successive winnowing as the snapshots age. I keep all snapshots for a week. Then one snapshot per week for a month. Then one snapshot per month for a year. Not perfect yet, still testing. But it is already in use daily.

You need to check that the drive is mounted before you start transferring files to it. Perhaps in the script that runs the rsync commands to do the backups.

Some quick googling gave this method:

if grep -qs '/mnt/foo ' /proc/mounts; then
echo "It's mounted."
else
echo "It's not mounted."
fi

USB is great for attended backups to removable media. When you can check that the drive is mounted before the backup starts. But I would never use it for unattended backups. If there is a problem you crash the root filesystem. USB is convenient but not reliable.

I wouldn't bother backing up the PLEX metadata folders. Instead make sure that the video files are backed up. In case all of the plexmediaserver files are lost plex can be reinstalled easily and automatically update and download the metadata again. But most likely the actual media files are not as easy to replace.

If you want FULL backups then you most likely have to stop everything running on the nas. The easiest way is to boot from some other media and mount the drives and backup that way.

Also make sure that you have versioned backups. Timestamped rsync snapshots. If you have a single copy of all the files, and update that copy daily, then errors and problems are propagated to the backup copy. Almost as fast as if you used RAID.

I don't use the OMV GUI for any backups. At all. I assume that it works fine, but I don't know exactly how and I don't feel in control. I use simple scripts that I have written and debugged and tested over the years and that I understand in detail. The scripts use rsync to create versioned rsync snapshots. And I run the scripts using cron jobs. I've done backups of Linux computers like this for a long time, since long before I knew OMV even existed.

Also I organize my filesystems so that it is easy to backup just the stuff I want to backup. And not stuff that doesn't need to be backed up. It saves a lot of space on the backup media and makes it possible to keep MANY versions of the important parts of the filesystem that is backed up.

There is no should. Whatever works is OK. Most likely the most efficient way to copy the files would be if both HDDs are connected to the same Linux computer over SATA. But if you are not in a hurry then you can most likely do the transfer over the network or with one or both HDDs connected using USB. Even over USB 2.

Linux computers can read and write windows filesystems. But it is much more difficult for a windows computer to read a Linux file system. It is like the Americans or British speaking a second language or not...

But using a Linux file system on a Linux computer is much faster than using a windows file system.