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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.