New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DietPi-Software | UrBackup default backup directory #545

Closed
pfeerick opened this Issue Oct 4, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@pfeerick
Copy link

pfeerick commented Oct 4, 2016

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

This comment has been minimized.

Copy link
Owner

Fourdee commented Oct 4, 2016

@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

This comment has been minimized.

Copy link
Author

pfeerick commented Oct 5, 2016

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

This comment has been minimized.

Copy link
Owner

Fourdee commented Oct 6, 2016

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 Fourdee modified the milestone: v133 Oct 6, 2016

@Fourdee

This comment has been minimized.

Copy link
Owner

Fourdee commented Oct 7, 2016

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.

Fourdee added a commit that referenced this issue Oct 7, 2016

v133
+ Force eth speed setting: #544
+ ethtool installed by default:
#544
+ Urbackup server installation updated to 2.0.36:
#545
@pfeerick

This comment has been minimized.

Copy link
Author

pfeerick commented Oct 8, 2016

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

This comment has been minimized.

Copy link
Owner

Fourdee commented Oct 8, 2016

@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.

@Fourdee Fourdee added the NoFix label Oct 8, 2016

@Fourdee Fourdee closed this Oct 8, 2016

@Fourdee Fourdee added the ARMv8 label Oct 8, 2016

@pfeerick

This comment has been minimized.

Copy link
Author

pfeerick commented Oct 9, 2016

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

This comment has been minimized.

Copy link

uroni commented Jan 13, 2017

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment