weewx.sdb on a Shared Drive?

[Wayne]

Instead of running the weewx database my Raspberry Pi 4 microSD card I'd like to relocate it to a shared drive on a Synology NAS.  This is mainly to take advantage of the data redundancy of the NAS.

1.  Is this simply a matter of changing SQLITE_ROOT to point to the new location?

2.  Any reason to not use a remote host in this manner?

An alternate solution is to periodically backup the file weewx.sdb but I just prefer having the database on the RAID storage device in the first place.

[vince]

Folks do that, sure.   You could get there with a symlink too if you wanted to not mess with weewx.conf

Years ago sqlite recommended not having the db remotely mounted, but I think there are old threads here suggesting weewx is pretty safe to do this setup on.

[Rainer Lang]

As long as you are aware that using RAID is NOT a replacement for backups, all is fine. You can put your weewx.sdb +/- "anywhere".

But if for whatsoever reason your database gets corrupted, the RAID (whichever number) won't be of any help.
RAID is a concept for higher performance and for disk redundancy, not a backup. For such events like data corruption or database corruption you need a backup.
Of course the backup can be made to another RAID system. 😉 And the backup be better regular with not too long intervals in between.

Amongst system administrators there is the (in-)famous saying: no backup - no pity.

The solution is better performance and redundancy against disk failure by RAID together with a proper backup concept of the database outside your operational RAID disks.

My database is on an industrial SLC microSD card on my Rpi4B (little risk to fail), and I'm using a five minute backup to an external disk (USB3, 2.5", 2 TB)
which will be "condensed" into an hourly backup by some housekeeping tasks/jobs/scripts every 2-3 days.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/3278acbc-d6ec-4d9d-bc01-702b0c6db14en%40googlegroups.com.

[Tom Keffer]

It's not generally a good idea to do this. There are two reasons:

1. There is a lot of traffic between the SQLite engine and the remote file system. Adding a network link can dramatically reduce performance.
2. More importantly, to achieve ACID properties, SQLite assumes that a fsync() call means all data was written to hard store, or will soon be written, before any subsequent writes. By contrast, in a network connection, the order of packet arrival is not guaranteed. The result is that getting fsync() to work over a network is hard. Sometimes, in the interest of performance, corners are cut. To be sure, they are corner cases, but they do happen.

Net-net: as Rainer says, if your goal is data integrity, you're better off doing proper backups. If your goal is remote database access, you're better off using MySQL.

Hope that helps.

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d67ef9df-3e5e-488a-bc9a-39dc2f8881bcn%40googlegroups.com.