As mentioned I'm working on making my d-i-y backup script as secure as my existing rsnapshot one, to this end I have added a bit more detail to my pseudo-code as follows:-
'Parent' script on backup client (my desktop), run every day in the small hours
Call 'child' script on NAS via dedicated ssh login which can only run the specified script. This is just a collection of 'mv' and 'rm' commands so doesn't take much processor power.
IF (day_of_month = 1) IF (month = 1) # i.e. January 1st rename month12 to this_year ELSE remove month12 FI rename month11 to month 12 .... month1 to month2 rename day31 to month1 ELSE remove day31 FI move day30 to day31 .... day1 to day2 exit (returns control back to 'Parent')
rsync with the --link-dest=DIR pointing to day2
The rsync that runs on the parent can be operated it two different ways such that it can *only* modify/write todays backup:-
1 - Use an rsync server on the backup NAS configured so that the only directories visible are 'today' (read/write) and 'yesterday' (read only, for the --link-dest to point at)
2 - Mount the two required dirctories on the client using NFS with permissions as in 1. The run the rsync 'locally' on the client.
I think (from previous disk speed tests I have done) that 2 will be significantly faster than 1, it's also rather simpler as rsync server configuration is rather odd (it's the way I secure my existing backup system on the old, full-up NAS)
So, views on the algorithm above (the guts of the script to run on the NAS) would be welcome. It really is only a dozen or so lines of shell script as far as I can see.
Another good thing is that I can run up and test virtually the whole set-up on one (desktop) machine, then move the disk drive to the NAS, change 'localhost' to the NAS hostname and it should still work. (No doubt a few things will need changing but the principle is good and also the first, full, backup will be in place).