Upgrade from old OMV (2.2.14) to recent OMV (5 or 6 after release)
-
- OMV 2.x
- tom_tav
-
-
Thanks, perfect!
-
So, i need some more input from you guys.
Im happy with the new OMV and will keep it. Will change the old mdadm raid to ZFS raid.
Im not sure where to put the OMV base system (its right now on a very old hdd which is already on smart alert):
1. i put it on the 64GB SSD
2. i put it on a USB stick and use the 64GB SSD as cache drive for the ZFS pool
What do you think? -
Im not sure where to put the OMV base system
I use a 32GTB usb flash drive (3 in total) I rotate them on a monthly basis, so I always have a usable backup, I don't have a cache drive for ZFS, no more connections left
Docker and containers are on a laptop drive, which I don't back up as the containers are deployed using stacks, which I keep copies of.
-
How many of your usb flash drives used for OMV did go bad during the last years?
-
How many of your usb flash drives used for OMV did go bad during the last years
None
-
How many of your usb flash drives used for OMV did go bad during the last years?
Wear of flash memory is minimized using the flashmemory plugin, downside is the lack of up-to-date log files in case of an OS crash
-
Wear of flash memory is minimized using the flashmemory plugin
Correct
downside is the lack of up-to-date log files in case of an OS crash
And where did you get that useless piece of information, there is no lack of log files on a usb flash drive, if there is a system crash then you'll need the most recent sys log
-
How many of your usb flash drives used for OMV did go bad during the last years?
The same here, none. I have 3 USB 16GB drives for my main server. They are a primary, a backup and a 3rd in the reserve that only gets updated if I change the functionality of the NAS. I've been using one drive, primarily, for over 4 years. It's still good.
You will, however, need to install the flashmemory plugin to support using a thumbdrive to boot. You'll need -> OMV-Extras. Once that's installed, you'll be able to find and install -> the flashmemory plugin.
______________________________________________
After creating your ZFS pool, consider running the following on the CLI, before copying data into the pool's filesystems. This sets up Linux equivalent permissions to include ACL's if you decide to go that route. (Compression is a free bonus.)
(Sub in the name of your pool for ZFS1)
zfs set aclinherit=passthrough ZFS1zfs set acltype=posixacl ZFS1
zfs set xattr=sa ZFS1
zfs set compression=lz4 ZFS1
-
So you have all 3 USB connected permanently and do a alternating backup from the boot one to the two backup USB drives?
This would be a ok solution for me, anything where i need to change manually from time to time is not possible/useful for my case.
Right now i have the system already moved to the SSD but im still tempted to try the ZFS caching. On the other hand, for a media server it doesnt make much sense....P.S. is the flashmedia plugin just for usb stick or also useful for ssd?
-
Something different im fighting with at the moment:
I did backup the raid to an external 8TB hdd with rsync:
time rsync -aHAXxv --numeric-ids --delete --progress --stats /srv/{source uuid} /srv/{destination uuid}
Now i just wanted to bring the backup up to date and did rerun it (in dry mode). Well it wants to copy all files again.
Number of files: 573,807 (reg: 341,491, dir: 206,665, link: 25,651)
Number of created files: 573,807 (reg: 341,491, dir: 206,665, link: 25,651)
Number of deleted files: 0
Number of regular files transferred: 341,491
Total file size: 7,836,673,846,395 bytes
Total transferred file size: 7,836,671,442,073 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 720,805
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 27,205,773
Total bytes received: 1,934,979
sent 27,205,773 bytes received 1,934,979 bytes 84,100.29 bytes/sec
total size is 7,836,673,846,395 speedup is 268,924.90 (DRY RUN)
Could it be the changed ACLs? I thought rsync will just touch it and not transfer the files again
-
Could it be the changed ACLs?
How did the permissions or ACL's get changed in the destination? If they did, yes, the changed files would be deleted (they don't exist in the source) and be recopied. As a rule thumb (that I use) when an Rsync copy is complete, I immediately run it again to verify that all went well with the first copy. In a large copy, recopying a few files or minor issues is not uncommon if, for example, the server becomes really busy with something else. When a job is run and no files are copied, you'll have a functional mirror.
So you have all 3 USB connected permanently and do a alternating backup from the boot one to the two backup USB drives?
No. My cloned thumbdrives are cold. One is sitting on top of the case and the other is in a drawer. They're copied with an off-line -> process.
-
On my Raid (the source) i did do new users/shares/.... with the new OMV5 install so there the ACLs changed.
I think i will use a thumbdrive for boot and do the backup on my other nas. If the thumbdrive breaks i just need to recreate it from this backup.
-
And where did you get that useless piece of information,
https://openmediavault.readthe…the-purpose-of-the-plugin
data in a RAM buffer & intended to be written to drive at a later time, can't exist at the same time on the drive => logs are small pieces of data , hence at time of a crash the logs can't be written out to the drive => incomplete logs
This understanding of "implications of buffering" is a basic fundamental in IT development -
Well if you need accurate logs you use a log server with remote logging anyways....
-
logs are for troubleshooting! Do hobbyists have remote logging servers?
-
logs are for troubleshooting! Do hobbyists have remote logging servers?
The point your are trying to make is moot as the plugin should also be used on SSD's, and TBH this continues to emphasise the importance of having a backup of your OS drive.
Again to emphasise the point you are making, do hobbyists actually have backups!!
-
-
plugin should also be used on SSD's
Disagree with this statement, because SSD controllers have advanced algorithms for wear leveling and memory over provisioning to compensated for failed flash memory cells. These technics are NOT used for memory cards, hence they fail much faster than SSDs with the same capacity.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!