What I do is outlined in the weewx wiki here:
https://github.com/weewx/weewx/wiki/Using-the-RSYNC-skin-as-a-backup-solution
I added the following to weewx.conf:
*[[RSYNCSQL]] # This backs up the sqlite databases to Diskstation
skin = Rsync HTML_ROOT = /home/weewx/archive
server = 10.0.10.225 user = weewx path =
/volume1/homes/weewx/archive_backup # every night at
midnight, run this report report_timing = @daily
delete = 0*
The nice thing is that the backup is run synchronously within weewx
ensuring the database is not being written to during the copy. From here -
on my Synology NAS - I can set up a cron-driven backup script as you do, or
utilize a purpose-written backup program like Duplicity.
I haven't done that last part yet, so I need to catch any corruption within
24 hours or my copy is overwritten by the corrupted database file. But, I
plan to implement a backup that gives me multiple snapshots to choose from
if I need to do a restore. I'm pretty sure Synology has a couple of backup
packages that I could use.
In the meantime, I can increase the time between rsync copies, as my Davis
console should buffer about a week's worth of archive data. That would
give me more time to react to any database corruption.
phil
On Wednesday, December 12, 2018 at 2:34:24 AM UTC-5, Dave Harper wrote:
>
> Gary,
>
> The backup strategy I use is a Python script I wrote that is started by
> cron every night. I had read that there could be a problem if the database
> is copied while it's being updated. The database is updated once a minute
> by weeWX so the script monitors the mtime of the weewx.sdb file, waits for
> the timestamp to change then waits about 15 seconds more before copying it
> to a subdirectory off my home directory. I also copy the /etc/weewx
> directory into the same backup subdirectory and then the script calls
> Duplicity to do the actual backup. Duplicity works by starting with a full
> backup the first time around and then doing incrementals from then on. A
> restore starts with the original full backup and then applies all
> incremental changes to get to the target restore date. To keep a restore
> process within reason, I only do a month of incrementals and on the first
> of each month the script creates a new monthly directory on the NAS. This
> strategy has seemed to work well over the past year or so and looking into
> why it failed this time around will be one of the top priorities for
> tomorrow.
>
> Dave
>
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
