DietPi-Software | UrBackup default backup directory

[pfeerick]

Just did an update to v132 on a Pine64, and thought I'd install some more software bits whilst I was at it. I installed UrBackup, and noticed when I started it up the first time that it had the following error message.

Can access /
Cannot access /C:\urbackup. No such file or directory (code: 2)

I can see that a directory was created under /mnt/dietpi_userdata/urbackup, and the installation instructions do mentioned changing the path, but shouldn't the launcher be setting that config value itself as part of it's optimisations (although since it appears that the settings are in a database file, it may not be that practical to do... :-/)?

If not, if might be good to mention that in that software note/guide linked above, as it's not an optional configuration change! ;-)

[Fourdee]

@pfeerick
Yep, although, i was unsuccessful in finding a urbackup configuration file/method/option , to have /mnt/dietpi_userdata applied by DietPi.

I'll need to take another look

[pfeerick]

Yeah, when I went digging around for config files, it looked like it was probably a database file, so I thought it was probably a 'too hard to change' value so thus only worthy of a first run configuration note. After a little more digging around, I came across this documentation on the config database, so will poke around further and see if I can spot the pertinent field, etc.

[Fourdee]

Found the value, cant seem to change it (i'am SQL novice):

root@DietPi:/etc/urbackup# find / -type f -name backup_server_settings.db
/var/urbackup/backup_server_settings.db

sqlite3 /var/urbackup/backup_server_settings.db

sqlite> SELECT * FROM settings;
backupfolder|/mnt/dietpi_userdata/urbackup|0

sqlite> UPDATE settings SET backupfolder='test';
Error: no such column: backupfolder

Might be easier just to create the .db with the settings we need, then copy it during installation. This would also cover if the sql db isnt generated until web interface is accessed for 1st time.

[Fourdee]

Generated a .db, copied over the .db after a clean installation, doesn't like it, need another method:

root@DietPi:~# systemctl status urbackupsrv.service
● urbackupsrv.service - UrBackup Client/Server Network Backup System
   Loaded: loaded (/etc/systemd/system/urbackupsrv.service; disabled)
   Active: failed (Result: exit-code) since Fri 2016-10-07 16:28:23 BST; 3min 35s ago
  Process: 18685 ExecStart=/usr/local/bin/urbackupsrv run --config /etc/default/urbackupsrv --no-consoletime (code=exited, status=5)
 Main PID: 18685 (code=exited, status=5)

Oct 07 16:28:22 DietPi urbackupsrv[18685]: WARNING: SQLite: duplicate column name: delete_pending errorcode: 1
Oct 07 16:28:22 DietPi urbackupsrv[18685]: ERROR: Error preparing Query [ALTER TABLE clients ADD delete_pending INTEGER]: duplicate co...in 1s...
Oct 07 16:28:23 DietPi urbackupsrv[18685]: WARNING: SQLite: duplicate column name: delete_pending errorcode: 1
Oct 07 16:28:23 DietPi urbackupsrv[18685]: ERROR: Error preparing Query [ALTER TABLE clients ADD delete_pending INTEGER]: duplicate co..._pending
Oct 07 16:28:23 DietPi urbackupsrv[18685]: WARNING: SQLite: statement aborts at 1: [ROLLBACK] cannot rollback - no transaction is acti...rcode: 1
Oct 07 16:28:23 DietPi urbackupsrv[18685]: ERROR: Error in CQuery::Execute - cannot rollback - no transaction is active  Stmt: [ROLLBACK]
Oct 07 16:28:23 DietPi urbackupsrv[18685]: ERROR: SQL: cannot rollback - no transaction is active Stmt: [ROLLBACK]
Oct 07 16:28:23 DietPi urbackupsrv[18685]: ERROR: Upgrading database failed. Shutting down server.

[pfeerick]

Hey... I was happy to complain about the problem... never said I was going to fix it! :-P

Ok, so I went and poked around sqlite, and bashed my head against a howto guide or two, and this is what I have come up with. Basically, you are updating something in the settings table to the value of /mnt/dietpi_userdata/urbackup when the key is backupfolder. Hence, you are updating the backupfolder entry in the settings table. Naturally test and retest on your end, but I can reproducibly break and fix the urbackup folder path now by simply changing the value parameter.

btw, my database path is different... it was in /usr/local/var/urbackup whereas yours was in /var/urbackup/ ... not sure what changed there...

systemctl stop urbackupsrv.service
sqlite3 /usr/local/var/urbackup/backup_server_settings.db "UPDATE settings SET value = '/mnt/dietpi_userdata/urbackup/' WHERE key = 'backupfolder'"
systemctl start urbackupsrv.service

[Fourdee]

@pfeerick

Hey... I was happy to complain about the problem... never said I was going to fix it! :-P

😆 If it works, full credit to you in changelog, and, I owe you a beer 👍

btw, my database path is different... it was in /usr/local/var/urbackup whereas yours was in /var/urbackup/ ... not sure what changed there...

.deb installation is /var/urbackup/backup_server_settings.db.
Sourcebuild (ARM64) is /usr/local/var/urbackup/backup_server_settings.db

Although, with .deb install, we set the following:

echo -e "urbackup-server urbackup/backuppath string $FP_DIETPI_USERDATA_DIRECTORY/urbackup" | debconf-set-selections

So its

• Only sourcebuilds (ARM64) that needs the sql change.
• Also need to install sqlite3 during installation.

When we stop service and apply sqlite3 /usr/local/var/urbackup/backup_server_settings.db "UPDATE settings SET value = '/mnt/dietpi_userdata/urbackup/' WHERE key = 'backupfolder'" at the end of installation, fails to run:

2016-10-08 12:28:24: ERROR: SQL: cannot rollback - no transaction is active Stmt: [ROLLBACK]
2016-10-08 12:28:24: ERROR: Upgrading database failed. Shutting down server.

urbackupserver performs this upgrade during 1st run.

So whats probably happening is the database is being "upgraded", values change, tables change. So we have no way of knowing which value we need to set during this upgrade. Even if we stop the service straight after installation, we have no sure way of knowing which database upgrade its reached, and, what variable we need to change.

I'am not going to spend any more time on this, marking as No Fix.

[pfeerick]

Fair enough... as you say, it looks like the database is in a state of flux during the first-run phase, so whilst the changes worked for me after that process, it b0rks things if you run it beforehand. And I only encountered it as the deb builds let you set the path, and that is only required on the ARM64 arch (hopefully not for too much longer). I suppose I could have a look at the initial database, to see what is going on there, but it's probably not worth it.

[uroni]

Hi,

came across this issue. If you want to fix it, write the backup folder to $LOCALSTATEDIR/urbackup/backupfolder and it will pick it up from there at first startup.
That is also what the Debian package at https://hndl.urbackup.org/Server/2.0.38/urbackup-server_2.0.38_armhf.deb does (see the postinst file in the package).

[MichaIng]

I also just came across this:

• So service needs to start one time to generate the database.
• No chance we can pre-create it. If values/structure changes, our pre-build breaks things.
• Database scheme is migrated on first service start as well, taking some time. If we'd find a way to know when this has finished, we could do the adjustment afterwards.
• We could scrape the log file. It is not cleared unexpectedly since cron service is stopped 🤔.
• Sadly I have to run a long taking re-compilation to catch the related log file output...
• Next issue, if some rewording or locale related change happens, our waiting loop will run forever. Also not sure on reinstalls with existing database, if migration is done in every case....

Okay forget it, as long as there is no pre-compile time config or env var that we can set, ARMv8 users must do the unbelievable heavy task of three web UI clicks 🤣.