after installing dietpi-sync, I found it is a 100% interactive tool.
It does not include a way to
define multiple sync activities (e.g. to sync 3 or 4 folder “couples”)
schedule each of them to have them automatically carried out at various times during the day
ideally: send an email with the result of the operation
(or at least, I did not see it)
The above is what can normally be done by using some higher-level sw like OpenMediaVault for example (and others)
My fundamental question is: how much can I “develop” onto the basic dietpi-sync tool to manually implement what I’m looking after, without disrupting the underlaying dietpi install ?
The workaround I am using for now is to nfs-export folders from all dietpi machines, mount them all onto a single OMV machine, and use the central OMV machine as a centralised Rsync hub.
You can modify /DietPi/dietpi/dietpi-sync without any issues for the underlying system. Our scripts do never call this script, besides /etc/cron.daily/dietpi if daily cron execution has been enabled.
Although I already have ideas on how to implement the features into the script and by this also merge dietpi-backup into it, I would be interested in your solution if you developed one and are willing to share with use .
Dear Micha thank you so much for your undeserved hopes on my abilities but - alas - they are indeed undeserved.
Whilst I do have a programmer’s past so to speak, my coding knowledge is stuck back to the late 80’s and while keeping a lot of interest and fun on playing with pcs etc I simply do not have the time to put myself up to speed on basic knowledge so as to be able to develop something even quite simple like this myself.
What I will try on my dietpi box(es) is quite simply treat the installed rsync package as I would on a bare debian box, and manually put up an rsync server daemon with a couple of folders (“modules” I think rsync calls them) published as reachable.
This way I will still be able to use my (sole) OMV box as a central rsync server, scheduling pull or push jobs as appropiate from/to the various dietpis on the lan, and easily getting email feeback after each op is carried out.
Such approach (if it works) should be a tiny bit better than NFS-export from dietpi, NFS-mount on OMV, and push/pull “fake local” on OMV, exactly because continued NFS connection would not be required.
The rsync plugin for OMV is very complete, you might simply take a look at that for ideas on WHAT (if not how) to develop within dietpi !
My fundamental question is: how much can I “develop” onto the basic dietpi-sync tool to manually implement what I’m looking after, without disrupting the underlaying dietpi install ?
Jep manually using rsync as usual of course works. Aside from our own scripts (+ boot, login and cron jobs) DietPi is basically Raspbian/Debian.
And jep using rsync internal remote transfer + daemon capabilities makes sense instead of having an additional network protocol (NFS/Samba) in between.
TL;DR: When used at Debian level, rsync does work as supposed “under” Dietpi.
I did configure rsyncd (AKA “rsync daemon”) to have my old Raspi-1 act as a target for PUSH rsynce remote jobs configured and scheduled from another machine (in my case, an OMV instance) the “basic” way that is
created /etc/rsyncd.conf file
created /etc/rsyncd.secrets file
started service as
rsync --daemon
On the opposite end the trick is knowing/remembering that in rsync jargon
user@ip:/Module addresses an rsync instance
user@ip::/Module addresses an rsyncd instance
.