I would’ve NEVER ever moved to Joplin if it wasn’t able to sync with WebDAV. I’m not into having a special daemon running on a server for that task, makes zero sense.
Seconding what others have already said. You should ABSOLUTELY NOT directly back up /var/lib/postgresql if that’s what you’re doing right now. Instead, use pg_dump: www.postgresql.org/docs/current/backup-dump.html
This should also give you smaller and probably more compressible backup sizes.
I use it just as a simple as possible, instructions on how I setup backups, important thing about container’s config, etc etc. I find it easier to just have a folder “Server” and put each container in a separate note or folder. It’s too much thinking about tags, links, pages and all in logseq, notes seem all over the place.
Yep, now, I initially found the daily journal approach a bit strange, but I use this for work as much as personal stuff, so it actually helps…
My suggestion to your usecase would be to keep a page per “thing” ie server / container / etc and then when you make a change you can just say (on that day’s journal page):
‘’ Setup a backup for [[Server X]] and it’s going to [[NAS2]] (for example) ‘’
Then, on either of those 2 pages you’ll automatically see the link back to the journal page, so you’ll know when you did it…
I think you can disable the journal approach if it’s not useful…
But, the important part is, the files underlying the notes you’re making are in plain text with the page name as the filename, whereas with Joplin you could never find the file…
Also, if you modify the file (live) outside of Logseq, it copes with that and refreshes the content onscreen.
And the links are all dynamic… renamed the NAS? Fine, Logseq will reindex all the pages for you…
It’s undergoing massive development, it basically went from nothing to nearly full featured in two years.
The breaking change just means you need to actually do something before updating. The software isn’t quite ready to be put on auto-update yet. Honestly the way the devs aren’t afraid to break things I think has contributed to the fast development.
Just be sure to keep a secondary backup of your photos which you should do either way.
I usually interpret the phrase “drop in” to mean that the replacement being referenced will also work with everything written for the original. Does “drop in” in this case mean that Immich will transparently replace Google Photos, similar to how libretube replaces YouTube? That would be amazing!
I think you need to learn more about how databases work. They don’t typically reclaim deleted space automatically for performance reasons. Databases like to write to a single large file they can then index into. Re-writing those files is expensive so left to the DBA (you) to determine when it should be done.
And how are you backing up the database? Just backing up /var/lib/postgres? Or are you doing a pg_dump? If the former then it’s possible your backups won’t be coherent if you haven’t stopped your database and it will contain that full history of deleted stuff. pg_dump would give you just the current data in a way that will apply properly to a new database should you need to restore
You can also consider your backup retention policy. How many backups do you need for how long?
You are right, I should. They are a bit more complicated than I anticipated, and apparently I’m doing everything wrong, haha. I have backups set up to go 2 years back, but I’m checking backblaze occasionally to check, so it shouldn’t be an issue. I have two months so far lol Thanks for the write-up :)
Did you know that you can use Joplin on a standard webdav server? Basically it just takes up the space of the data itself. I have it on a Caddy server and works like q charm synching between Windows and Android client
selfhosted
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.