The Linux command line interfaces have been redesigned since then as well.
This version now includes a Mac OS X client and a portable Linux client (for x86/x86_64/ARMv6/ARM64). I did not manage to get different OS X versions to run in Virtual Box. If anyone has pointers on how to do that in a comfortable and legal manner they would be appreciated.
The portable Linux client doesnāt have C+Ā±exception support (yet). In my tests everything was functional but this is something that must be resolved before releasing a non-beta version.
Changes since last version
Fixed restore
Improved progress reporting for image restore
Fixed image restore with raw images (btrfs)
Cope with /etc/sysconfig not being present during Linux install (untested)
Todo
Linux and Mac OS X client update is untested as of yet
UEFI/GPT testing
Update documentation
Compatibility with prior versions
2.x server with 1.4.x client full compatibility (please report issues)
2.x client with 1.4.x server works only in local network mode (not via internet mode)
Older client/server combinations may work but were not tested
1.x restore does not work with 2.x servers (improved login method)
Upgrade process
As always: Replace the executables and the database of the server/client will be updated on first running it. As always downgrading the database version after upgrading it is not possible, so you should backup the old database files especially since this is a beta.
Because of the improved file deduplication and statistics calculation the largest server table has to be completely rebuild. This may take a few hours depending on how many file entries you have. It will show the progress on the web interface but is not usable during the upgrade process.
Linux notes:
The wrapper scripts start_urbackup_server and start_urbackup_client have been removed. Please use the executable directly
The executable has been renamed to urbackupsrv (from urbackup_srv), the client to urbackupclientbackend (from urbackup_client)
There is a new command line interface for the client urbackupclientctl
All the plugins are now statically linked into one executable. This simplifies the compilation, debugging and packaging on Linux
Run the UrBackup server on Linux with e.g. urbackupsrv run --loglevel debug
Ok after upgrading server to 2.0.4beta Iāve noticed client downloads from the web interface are no longer working giving the same signature error from earlier beta before you fixed it.
I can confirm it works on Linux and Windows on āsimpleā paths. On āDocuments and Settingsā, I still canāt resume (the pop up doesnāt even shows and the server log says it hasnāt any hash for that file/path).
Just tested, worked perfectly
Tested,the configuration file is now present also on Arch Linux.
Hi, it seems a little bug introduced itself in āurbackup_snapshot_helperā since beta 2.0.>0 I straced it back to an erroneous ā-cā parameter being passed to ābtrfs subvolume deleteā :
This makes the snapshot helper fail every btrfs test.
root@icts-q-dcvm-4:/usr/bin# ./urbackup_snapshot_helper test
Create subvolume '/media/BACKUP/urbackup/testA54hj5luZtlorr494/A'
Create a snapshot of '/media/BACKUP/urbackup/testA54hj5luZtlorr494/A' in '/media/BACKUP/urbackup/testA54hj5luZtlorr494/B'
ERROR: error accessing '-c'
Delete subvolume '/media/BACKUP/urbackup/testA54hj5luZtlorr494/A'
TEST FAILED: Removing subvolume A failed
ERROR: error accessing '-c'
Delete subvolume '/media/BACKUP/urbackup/testA54hj5luZtlorr494/B'
TEST FAILED: Removing subvolume B failed
āurbackup_snapshot_helperā from beta 2.0.0.0 works fine:
root@icts-q-dcvm-4:/tmp/unpack/usr/bin# ./urbackup_snapshot_helper test
Create subvolume '/media/BACKUP/urbackup/testA54hj5luZtlorr494/A'
Create a snapshot of '/media/BACKUP/urbackup/testA54hj5luZtlorr494/A' in '/media/BACKUP/urbackup/testA54hj5luZtlorr494/B'
Delete subvolume '/media/BACKUP/urbackup/testA54hj5luZtlorr494/A'
Delete subvolume '/media/BACKUP/urbackup/testA54hj5luZtlorr494/B'
TEST OK
Update: this happens on Ubuntu 14.04, which apparently uses an older ābtrfsā where the ā-cā option to subvolume delete does not yet exist.
Seems to be working mostly OK, so thank you very much for your hard work
I did have issues initially where files would only very slowly be removed from the file queue, as urbackup was searching for the file hashes of teh previous full file backup and couldnāt read them.
I got around this by deleting the clients and readding them since they were test machines.
Other than that, I am getting āerror setting filetimeā warnings at the ends of Backups. Does this have anything to do with atime not being set ?
E: Some index files failed to download. They have been ignored, or old ones used instead.
When selecting option 4 for no snapshots says:
Detected Debian (derivative) system
Detected systemd
Stopping currently running client serviceā¦
Detected architecture x86_64-linux-eng
Installing systemd unitā¦
Starting UrBackup Client serviceā¦
Successfully started client service. Installation complete.
+Detected Ubuntu. Dattobd supported
-Detected no btrfs filesystem
-LVM not installed
Please select the snapshot mechanism to be used for backups:
This is something that needs improvement. Thanks for the hint!
It seems it needs a fallback for older btrfs-tools. Thanks for the hint!
Your server probably downloaded it while I was uploading or your download got interrupted.
Ok, will have a look at this.
No, Iām getting this sporatically as well but havenāt looked at it yet. This is only a ābeautyā thing. It sets the file times of the files in the backup storage to the file times of the files being backed up. Those file times are then not used again. For restore and the web interface the internal metadata is directly read and used.
Hello,
with 2.0.4, Iām noticing one (blocking) problem: the backup starts indexing, then hangs. The client log shows a lot of:
[ā¦]
2016-02-13 04:13:47: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:13:47: Active query(0): END;
2016-02-13 04:13:57: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:13:57: Active query(0): END;
2016-02-13 04:14:07: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:14:07: Active query(0): END;
2016-02-13 04:14:17: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:14:17: Active query(0): END;
2016-02-13 04:14:27: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:14:27: Active query(0): END;
2016-02-13 04:14:37: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:14:37: Active query(0): END;
2016-02-13 04:14:47: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:14:47: Active query(0): END;
2016-02-13 04:14:57: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:14:57: Active query(0): END;
2016-02-13 04:15:07: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:15:07: Active query(0): END;
2016-02-13 04:15:17: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:15:17: Active query(0): END;
2016-02-13 04:15:27: SQLITE_BUSY in CQuery::Execute Stmt: [END;]
2016-02-13 04:15:27: Active query(0): END;
2016-02-13 04:15:37: ERROR: SQLITE: Long running query Stmt: [END;]
2016-02-13 04:15:37: ERROR: Active query(0): END;"
The servers stays in āIndexingā state, the client continues with:
2016-02-13 04:19:06: Looking for old Sessionsā¦ 0 sessions
2016-02-13 04:49:07: Looking for old Sessionsā¦ 0 sessions
2016-02-13 05:19:08: Looking for old Sessionsā¦ 0 sessions
2016-02-13 05:49:09: Looking for old Sessionsā¦ 0 sessions
2016-02-13 06:19:10: Looking for old Sessionsā¦ 0 sessions
2016-02-13 06:49:11: Looking for old Sessionsā¦ 0 sessions
2016-02-13 07:19:12: Looking for old Sessionsā¦ 0 sessions
2016-02-13 07:49:13: Looking for old Sessionsā¦ 0 sessions
2016-02-13 08:19:14: Looking for old Sessionsā¦ 0 sessions
2016-02-13 08:49:15: Looking for old Sessionsā¦ 0 sessions
2016-02-13 09:19:16: Looking for old Sessionsā¦ 0 sessions
2016-02-13 09:49:17: Looking for old Sessionsā¦ 0 sessions
and everything is stuck this way.
This seems to happen only on larger servers, and not on first (full or incremental) backup, but on second/third after restarting the client.
Actually, it happens after one or two backups, without restarting the client. When indexing, that is the error message that shows, and everything hangs there. Restarting the client solves the problem, at least for the first backup. It usually happens when using with big servers or slow ones. It happens both with snapshot modes (datto and lvm) and normal.
Iām new to this nice thing that called āurbackupā, and iām starting to love it
Iāv installed this beta version (2.04) and i have question:
when the backup activity (first full backup) stopped suddnely because of unplanned server shutdown (where the urbackup server installed) the backup process wonāt start from the last place where it stopped. it will begin a new full backup directoryā¦ is it right? or there is something to do with it?
