Beiträge von Wasn

  • Best practise for backing-up/snapshotting a remote smb share to omv

    Zitat von ryecoaaron

    I know it works. /srv/UID-123456789 may have data in it but when you create a shared folder (used by rsnapshot), it creates a subfolder named the same as the sharedfolder name. Is there data in that subfolder?

    Just to be sure: For rsnapshot I need a shared folder. And when I tried to make a shared folder with the mountpoint created by remotemount I get this errors reported:



    What do I do different than you that it doesn't work for me?

  • Best practise for backing-up/snapshotting a remote smb share to omv

    Zitat von ryecoaaron

    I use this technique on a server. I know it works. /srv/UID-123456789 may have data in it but when you create a shared folder (used by rsnapshot), it creates a subfolder named the same as the sharedfolder name. Is there data in that subfolder?

    When I mount the (windows) smb share with remotemount in my omv (v3.0.99) server and then try to create a sharedfolder from the new mountpoint it just throw's errors like hell.


    This is my conclusion:


    What I want to achieve is a "simple" backup/snapshotting from the share without touching it (read-only style).

  • Best practise for backing-up/snapshotting a remote smb share to omv

    Zitat von ryecoaaron

    For no particular reason, I am doing a push rsync from the source to the target. So, the target has the server modules enabled. Nothing else special.

    I'm doing the same now with two OMV machines. Works without problems since over a month. :thumbup:



    Anyway I need to come back here because I have almost the same scenario now but with a little detail which makes the solution in this thread not possible.


    Difference is that there is not two but just one OMV server and the server which is serving the smb share is a windows machine. I'm almost breaking my head how to create a backup/snapshots of this share on the omv server (omv v3). <X

  • Best practise for backing-up/snapshotting a remote smb share to omv

    Zitat von ryecoaaron

    You are probably the first because most people don't do this with samba shares which necessitates the remote mount plugin doing weird things. I understand the benefits but you need to do it a different way.

    And I even added some more just this minute ;)



    Zitat von ryecoaaron

    That is actually what I do on OMV 4.x. It requires more storage but it is worth it. Very reliable and eliminates samba.
    I will try to look at the rsnapshot plugin to allow it to use a remote server for the source. Then you could run rsnapshot on the target server without creating the extra space requirement.

    Great! I will go this way for now! Good that you have it running proper already. Any special tips how to configure the rsync? I think the source should do the rsync server an the target is playing client and is pulling the things? The standard settings are for good or any suggestions to chance them?


    Pimping the rsnapshot plugin that it's possible to grab from the other nas would be awesome. Would be even better than my old omv2 setup :thumbup:

  • Best practise for backing-up/snapshotting a remote smb share to omv

    Zitat von ryecoaaron

    It is possible to use rsnapshot (although it is kind of dangerous since rsnapshot uses hard links which not all remote filesystems support properly) once you have created a sharedfolder using the remote mount.

    The source and target is a OMV 3.0.99 both using ext4 as file system.


    On my 'old' setup I have OMV 2.x running this (from a remote smb share) since many years without any problems. I also have a webdav mounted from which I do local rsnapshotting. Works wonderful and reliable.



    Zitat von ryecoaaron

    It doesn't mount the remote mount. It just creates the disk object. Once you create a shared folder, a mount is created. No tricks needed. If you get an error, then the setup/permissions are wrong and the OMV system can't create a folder on the remote share.


    Actually I can create a share >inside< the remote share. But I want to do rsnapshot with the share itself.


    I just created a new share on the source nas using the root of the disk (which is including the shares I want to do snapshotting). But it didn't work out. When I mount it on the target nas and create the rsnapshot job an hit start I get the little 'console' window with a overlay waiting (or something like this) followed by a completely white/empty window with a button 'close'. I tried couple of times but it's always empty and no error message is thrown.


    The other thing I tried is to create a shared folder on the 'remote mount'/disk without creating a new folder inside but rather use '/' of the disk. Here I also get the error:


    Code
    Failed to set file mode to '42775' ...




    Zitat von ryecoaaron

    You are the first to want this type of setup. Unfortunately, the plugin doesn't support this and would require porting the old plugin (I'm not going to do that) in order to do what you want. What I do want to do (someday) is change the rsnapshot plugin to allow remote hosts for the source but this would use the rsync protocol. Until then you can mount your remote shares manually and run rsnapshot manually or stay on OMV 2.x.


    First and hopefully not the last! For me this setup has a lot of advantages:

    • Extremely low on network traffic (just transferring the delta files which are changed or new on the source nas)

      • Therefor it's very efficient because uses less runtime transferring big amounts of data...
    • Extremely low power (using to arm boxes with gigabit with far enough horse power)
    • Extremely cheap (did I say it uses arm SoCs?)
    • Easy 'decentralized' Backup (for example one nas in the basement other in the second floor)
    • Easy archiving of the data (Thru snappshotting..)
    • Easy going with two one-bay-nas but far more benefits than a two-bay-nas
    • Taking advantages of different storage types: fast where necessary and cheap where possible (SSD to serve clients, HDD for backup and archive)
    • Having a quick disaster recovery in case of emergency (using same hardware. Through easiness of omv I just need to create a share and activate it on the backup nas to be back on track)
    • Many many more...

    Anyway I can't go with OMV 2.x anymore because things are in place and in 2018 it's anyway to late for it. I rather need to go another way. If I read your post I now need to do to both manually: The mounting of the shares and the rsnapshot? I never did this and I'm used to the gui so this is rather a ruff edge. ||
    What would be other possibilities with gui? Would it make sense to clone (rsync) the share from the source nas to the target nas and then create 'local' snapshots from this? Is this still possible?
    Or any other ideas? ?(


    Thank's for your explanations by the way! Hope that omv get's this feature back in the future! It's a little regression for me :whistling:

  • Best practise for backing-up/snapshotting a remote smb share to omv

    Hello,


    I tracked it down.

    The big difference is in the remote share plugin. For me it looks like a completely different plugin for omv 2.x vs omv 3.x    . And it got worse for me :/


    Problem is that the 'new' version in omv 3.x (beside that it now only supports smb/nfs and no more webdav etc.) does not 'register' the remote shares as shared folders. Therefor it's not possible to use rsnapshot because I can't chose the source folder (because it needs to be a shared folder). The 'new' plugin in omv 3.x rather mounts the remote share as a disk (I'm not sure if its a bug or a feature?).
    I tried to trick the system in creating a shared folder on the disk (which is the remote share) but than it's throwing errors in the shared folder tab when creating the share:


    Code
    Failed to set file mode to '42775' for '/srv/xyz123456-1234-1234-1234-abcdefg1234/Share'


    Even though the 'create window' stays open which would indicate that the creation of the shared folder failed but it got created anyway.


    More errors to come when opening the rsnapshot tab:


    Code
    Failed to execute XPath query '//system/shares/sharedfolder[uuid='zyx87654321-4321-4321-4321-gfedcba4321']'.


    I guess it's because omv tries to manipulate things in the remote share. I don't even want that to happen. I just want to have the remote share mounted (maybe even read only) and create snapshots from it to the local disk.


    The really bad thing about this. I just deployed a setup with two omv nas boxes and the snapshotting (which should be the remote backup and archive) does not work ;(


    The source is a NAS with SSD and limited space (500GB). Therefore it should just provide data shares. The target is a NAS with HDD and space (3TB) for the snapshots.


    What to do?

  • Best practise for backing-up/snapshotting a remote smb share to omv

    Hey there,


    I'm running a couple of omv setups and struggeling right now a little bit.


    I used to (omv2.x) use the remote share plugin to mount a smb (and webdav) share localy in omv.
    Then I used the rsnapshot plugin to create automatically snapshots from this remote (but locally mounted) drive.


    I now tried the same with omv3.x and it does not work out the way I expected.
    I can mount the smb share with the remote share plugin locally (somewhere to /srv/UID-123456789, probably the standard path)
    But my rsnapshot setup does only create local empty folders (hourly.0, hourly.1, ...) on my local disk even thought the remote share is proper mounted and filled with data.


    I now wonder what's going on here and if something changed between my versions of omv or if I just missing out something?



    Also I know want to know what is the best practise (web gui wise) to do this with a clean omv landscape. My plan for a new (old keeps in place) setup is with two omv machines. One running as master and the other as slave, It should do excactly the same: mounting the remote share from omv-master and locally (omv-slave) create snapshots. I don't want to sync snapshots because it creates far more traffic in the network and also omv-master has only a small SSD where omv-slave has a big HDD.


    I hope everything is clear :D

  • Error message smartctl in web ui

    Hello,


    I just burned a new image to a freshly (f3-checked) microSD card to get started the omvication of my odroid hc2.


    I went with 'apt upgrade' to get up to date (openmediavault 3.0.92 to 3.0.99) and everything went smooth except one little very annoying thing.



    Every time I hit the disc section in the web ui this error is thrown:

    Zitat von openmediavault webui

    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; smartctl -x '/dev/sda' -d sat 2>&1' with exit code '1': smartctl 6.4 2014-10-07 r4002 [armv7l-linux-4.9.61-odroidxu4] (local build)Copyright (C) 2002-14, Bruce Allen, Christian Franke, http://www.smartmontools.org/v…ls/drivedb/drivedb.h(86): Syntax error in preset option string




    I think it's because one decision I made while upgrading via terminal:



    I said no (default) to keep the old configuration... but as I know better now I had should say yes... :S


    I tried to get rid of this by force installing again with: apt install --reinstall openmediavault


    but no question here if I want the new configuration file...


    Is this fixable?

  • Building OMV automatically for a bunch of different ARM dev boards

    Zitat von tkaiser

    If it's not configurable then you might want to use symlinks. Stop OMV services, then move the directory containing the databases to the SSD and then set a symbolic link using 'ln -s' from SSD to original location.


    I spend the last to days a couple of hours finding out where the heck the data stored. As I found out the "default" target of rrd is changed in openmediavault and as well the technique to collect these data (collectd if I'm right?).


    The closest I came is this here: https://github.com/openmediava…diavault/mkconf/rrdcached


    Where for me (I don't have any coding skills so please correct me if I'm wrong) this one here would be of importance:



    I'm still not sure where the data is finally written and if it's possible to use the possibility of symlinks for changing the drive?
    Any help on this is highly appreciated! Thank's! ;)

  • Building OMV automatically for a bunch of different ARM dev boards

    Zitat von votdev

    You have to enable monitor data collection in the system menu.

    Zitat von tkaiser

    It's a feature since you're running off an SD card that gets destroyed pretty fast when the RRD databases are constantly updated. The problem is called 'write amplification' and I tried to collect everything important around SD cards here (check especially the links at the top): https://forum.armbian.com/topic/954-sd-card-performance/


    Very valid point that's disabled. Thank's for the link.



    Is there any chance to change the data collection target - so that I collect the numbers but write the RRD database to a attached SSD rather than the microSD?

  • Building OMV automatically for a bunch of different ARM dev boards

    Hello @tkaiser


    thank's a lot for this very nice flavor. I'm running it on a Orange Pi PC 2 since months without problems. Recently a Odroid HC1 went live and is working nicely.


    I just figured out one thing. Under "Diagnostics -> System Information -> Performance" none of the graphs is working. It's kind of a luxury but a nice one. The graphs should be created by rrd (in detail with rrd.php).


    The output right now is this on both boards (maybe on all arm flavors from omv?)




    Is it a bug or a feature? :P

  • Building OMV automatically for a bunch of different ARM dev boards

    Zitat von tkaiser

    Yes, but feedback here is useless since this already not related to OMV at all (but bleeding-edge kernel and settings stuff for ARM boards that are currently only really supported in Armbian soon).
    You could do some reboot tests and might then again running into problems (since the cpufreq scaling settings allow to downclock to very low clockspeeds and then SY8106A uses a very low VCore voltage, then the board reboots at 816 MHz and might run into troubles again).


    Currently /etc/defaults/cpufrequtils sets 408/816 MHz, maybe it's better to switch to 816/1296 instead. If feedback then please not here but in Armbian forum (see link above).

    So just to give feedback already. I had a lot's of reboots today (more than 5) and all worked. The system is super fast an snappy. Didn't had any trouble getting things running.


    Just one question: the flashmemory plugin should be installed by default? Because in my case it isn't. Is the underlying function (caching to ram instead to folder) implemented or is this missing in this release?

  • Building OMV automatically for a bunch of different ARM dev boards

    I'm already penetrating my new system and had the following error while installing the (for me) mandatory plugin luksencryption

  • Building OMV automatically for a bunch of different ARM dev boards

    Zitat von tkaiser

    There you go (please wait 15 minutes, it's uploading now): OMV_3_0_94_Orangepipc2_4.14.4.img.xz (MD5: ef8e16c68734d06bdd10cb11fcc8ec3e)

    What can I say?


    It works! Like it should! Non of the previous problems is left! The web gui works like it should and also the console is normally accessible. The device also did the reboot by itself!


    Thank you very much!


    Is there anything I can help with (no drugs & weapons please :P )?


    Here is a 'sudo armbianmonitor -u' just after reboot,adding a user and first login via ssh: http://sprunge.us/fYfJ

  • Building OMV automatically for a bunch of different ARM dev boards

    Zitat von tkaiser

    The other way around would make some sense. Anyway: I started the build system and currently a new build for OPi PC2 is created. I will provide the URL in an hour, will not test anything but if you report everything being fine then I'll rebuild the one for Orange Pi Prime too and try to replace both images at the download location (hmm... NanoPi M1 Plus 2 should also be affected...)


    Yea, I figured out... it was running as bad as before


    I try this one now:


    Code
    ENABLE="true"
GOVERNOR="ondemand"
MAX_SPEED="480000"
MIN_SPEED="480000"


    and I will test your image when released :thumbup:

  • Building OMV automatically for a bunch of different ARM dev boards

    Thank's a lot for your feedback. Even though I'm not quite sure what this means. From my point of view this is no hardware fault itself but more like a tolerance within the manufacturing process, correct? I never had problem's with the device so far (running kernels up to 4.10).


    I changed the values in /etc/default/cpufrequtils



    from, original:


    Code
    ENABLE="true"
GOVERNOR="ondemand"
MAX_SPEED="1296000"
MIN_SPEED="480000"

    to

    Code
    ENABLE="true"
GOVERNOR="ondemand"
MAX_SPEED="1296000"
MIN_SPEED="1296000"


    ...right now I give it a shot! Hopefully it will not burn :D