If I look at /var/urbackup and <urbackupfolder/urbackup, they have similar files. What is the purpose of these two directories?
I don’t want the root partition with /var/urbackup get filled up, so I symlinked /var/urbackup to /var_urbackup, but I get the following error:
WARNING: SQLite: os_unix.c:36982: (40) openDirectory(/var/urbackup) - errorcode: 14
I spite of the error, the backup server seem to work, but I am not confident because of this error.
Not sure what you mean by “urbackupfolder”? Do you mean the directory where your backups are stored? If so, that might be why it throws an error. The nightly “remove_unknown” might also remove the stuff, so be careful.
The things that you say are “similar files” are most likely backups of the settings, not sure. But you cant just smash things together and expect it to work if that was what you were going for.
I symlink /var/urbackup because I run urbackup on a rpi with an sd-card, so I want to store those files on a “real” drive, so I just symlinked it to another location.
I also chowned the symlink to urbackup, but I do not think that is nessesary tbh.
I run urbackup as root because of ZFS, so chown should not be a problem, as root can access every file and directoiry. Do you also get this error message?
Answer to the two directories: I moved the contents of /var/urbackup to the backup directory of urbackup (as var_urbackup). The second one urbackup comes from the backup of the database, which urbackups makes by default.
That kinda answers the question of why you get an error then.
Point the symlink to somewhere completely different (not the same dir as your backups, that should ONLY be given access to urbackup, but in your case it’s root I guess) and you should be gucci.
The location I choose was to make a home for the urbackup usr (when I created it) and place the stuff in a “database” directory there and symlinked /var/urbackup to that location. But since you run as root (witch I would recommend against btw, ZFS should not be a block for that, there is absolutely no reason for urbackup to run as root) I guess you have to choose another route.
Do not ever touch anything in the urbackup backup folder or add anything in there!
When the server runs its nightly cleanup, it also runs remove_unknown, witch removes ANYTHING that is not placed there by urbackup and therefore are referenced in the database.
No. I moved the directory out of the urbackup location to a complete other file system, and symlinked ot it. But still I get the following errors in /var/log/urbackup.log.
2023-09-30 19:10:44: WARNING: SQLite: cannot open file at line 36982 of [3bfa9cc97d] errorcode: 14
2023-09-30 19:10:44: WARNING: SQLite: os_unix.c:36982: (40) openDirectory(/var/urbackup) - errorcode: 14
I repeat, do not touch the stuff in the urbackup backup folder.
/var/urbackup is afaik not where urbackup stores backups by deafault.
The database however, that is a different story and THAT is what is stored there and is exactly what I have symlinked.
As I wrote, I do NOT link to the urbach backup folder any more, but to a different folder, but the error from SQLLite is still in the urbackup.log. Could you please check, if you also have this? The strange thing is, that in spite of the error it SEEMS to work, but the question is, what bad consequences this error might have.
I do not have any errors in my logs about the database, sorry (but not sorry xd)
/media/usr/urbackupserver is the home for the urbackup user account:
$ sudo getent passwd urbackup
urbackup:x:113:119:System user for Urbackup,,,:/media/usr/urbackupserver:/usr/sbin/nologin
The symlink is owned by urbackup.
(I should probably fix the credentials so only urbackup has access like in the backup folder)
This is what my setup looks like:
$ ls -l /var/urbackup
lrwxrwxrwx 1 urbackup urbackup 34 Jun 5 00:28 /var/urbackup -> /media/usr/urbackupserver/database
$ ls -l /media/usr/urbackupserver
drwxr-xr-x 1 urbackup urbackup 1552 Oct 6 11:47 database
$ ls -l /media/usr/urbackupserver/database
-rw-r--r-- 1 root root 24 Oct 11 2022 backupfolder
-rw-r--r-- 1 urbackup urbackup 52428800 Oct 6 11:47 backup_server.db
-rw-r--r-- 1 urbackup urbackup 163840 Oct 6 13:10 backup_server.db-shm
-rw-r--r-- 1 urbackup urbackup 73574992 Oct 6 13:10 backup_server.db-wal
-rwxr-x--- 1 urbackup urbackup 943718400 Sep 25 05:41 backup_server_files.db
-rwxr-x--- 1 urbackup urbackup 720896 Oct 6 11:47 backup_server_files.db-shm
-rwxr-x--- 1 urbackup urbackup 857994152 Oct 6 11:47 backup_server_files.db-wal
-rw-r--r-- 1 urbackup urbackup 8192 Oct 11 2022 backup_server_link_journal.db
-rw-r--r-- 1 urbackup urbackup 32768 Oct 6 05:09 backup_server_link_journal.db-shm
-rw-r--r-- 1 urbackup urbackup 436752 Oct 5 13:01 backup_server_link_journal.db-wal
-rw-r--r-- 1 urbackup urbackup 16384 Oct 11 2022 backup_server_links.db
-rw-r--r-- 1 urbackup urbackup 32768 Oct 5 13:01 backup_server_links.db-shm
-rw-r--r-- 1 urbackup urbackup 0 Oct 11 2022 backup_server_links.db-wal
-rw-r--r-- 1 urbackup urbackup 110592 Oct 6 11:47 backup_server_settings.db
-rw-r--r-- 1 urbackup urbackup 32768 Oct 6 12:30 backup_server_settings.db-shm
-rw-r--r-- 1 urbackup urbackup 1854032 Oct 6 12:30 backup_server_settings.db-wal
-rwxr-x--- 1 urbackup urbackup 197905 Aug 31 21:28 clientlist_b_2637.ub
-rwxr-x--- 1 urbackup urbackup 9095875 Oct 6 07:56 clientlist_b_2899.ub
-rwxr-x--- 1 urbackup urbackup 12293048 Oct 6 11:47 clientlist_b_2900.ub
-rwxr-x--- 1 urbackup urbackup 2883321 Dec 7 2022 clientlist_b_617.ub
-rwxr-x--- 1 urbackup urbackup 162 Oct 6 05:06 dataplan_db.txt
drwxr-x--- 1 urbackup urbackup 130 Oct 11 2022 fileindex
-rw-r--r-- 1 urbackup urbackup 83 Oct 11 2022 server_ident_ecdsa409k1.priv
-rw-r--r-- 1 urbackup urbackup 128 Oct 11 2022 server_ident_ecdsa409k1.pub
-rw-r--r-- 1 urbackup urbackup 23 Oct 11 2022 server_ident.key
-rw-r--r-- 1 urbackup urbackup 334 Oct 11 2022 server_ident.priv
-rw-r--r-- 1 urbackup urbackup 442 Oct 11 2022 server_ident.pub
-rw-r--r-- 1 urbackup urbackup 20 Oct 11 2022 server_token.key
-rwxr-x--- 1 urbackup urbackup 52 Oct 6 05:06 server_version_info.properties
-rwxr-x--- 1 urbackup urbackup 46160589 Oct 5 12:58 UrBackupUpdate.exe
-rwxr-x--- 1 urbackup urbackup 25458401 Oct 5 12:59 UrBackupUpdateLinux.sh
-rwxr-x--- 1 urbackup urbackup 102 Oct 5 12:58 UrBackupUpdateLinux.sig2
-rwxr-x--- 1 urbackup urbackup 40 Oct 5 12:58 UrBackupUpdate.sig
-rwxr-x--- 1 urbackup urbackup 102 Oct 5 12:58 UrBackupUpdate.sig2
-rw-r--r-- 1 urbackup urbackup 3 Oct 5 12:59 version_linux.txt
-rw-r--r-- 1 urbackup urbackup 3 Oct 5 12:58 version.txt
Everything seems to works fine for me and the nightly backup of the database to my urbackup backup folder works as planned… (/media/backup is my backup folder, cleanup starts at 5 am, no idea why the forum color codes it red)
$ sudo ls -l /media/backup/urbackup
-rwxr-x--- 1 urbackup urbackup 52428800 Oct 6 05:09 backup_server.db
-rwxr-x--- 1 urbackup urbackup 72462592 Oct 6 05:09 backup_server.db-wal
-rwxr-x--- 1 urbackup urbackup 943718400 Oct 6 05:10 backup_server_files.db
-rwxr-x--- 1 urbackup urbackup 857994152 Oct 6 05:10 backup_server_files.db-wal
-rwxr-x--- 1 urbackup urbackup 8192 Oct 6 05:10 backup_server_link_journal.db
-rwxr-x--- 1 urbackup urbackup 436752 Oct 6 05:10 backup_server_link_journal.db-wal
-rwxr-x--- 1 urbackup urbackup 16384 Oct 6 05:10 backup_server_links.db
-rwxr-x--- 1 urbackup urbackup 0 Oct 6 05:10 backup_server_links.db-wal
-rwxr-x--- 1 urbackup urbackup 110592 Oct 6 05:09 backup_server_settings.db
-rwxr-x--- 1 urbackup urbackup 1854032 Oct 6 05:09 backup_server_settings.db-wal
-rwxr-x--- 1 urbackup urbackup 197905 Oct 6 05:10 clientlist_b_2637.ub
-rwxr-x--- 1 urbackup urbackup 9080649 Oct 6 05:10 clientlist_b_2897.ub
-rwxr-x--- 1 urbackup urbackup 12292063 Oct 6 05:10 clientlist_b_2898.ub
-rwxr-x--- 1 urbackup urbackup 2883321 Oct 6 05:10 clientlist_b_617.ub
-rwxr-x--- 1 urbackup urbackup 83 Oct 6 05:10 server_ident_ecdsa409k1.priv
-rwxr-x--- 1 urbackup urbackup 128 Oct 6 05:10 server_ident_ecdsa409k1.pub
-rwxr-x--- 1 urbackup urbackup 23 Oct 6 05:10 server_ident.key
-rwxr-x--- 1 urbackup urbackup 334 Oct 6 05:10 server_ident.priv
-rwxr-x--- 1 urbackup urbackup 442 Oct 6 05:10 server_ident.pub
I do not feel comfortable giving advice about modifying the database, I do not posses enough knowledge. But I have seen here in the forum ppl mentioning rebuilding the database. I DO NOT TELL YOU TO DO THIS, I have just read about it and think it might be something you should look into…