Ability to reconnect during indexing if connection is broken
Define which volumes need to be snapshotted together (snapshot groups)
Major changes with client 2.1.x beta
Ability to reconnect during indexing if connection is broken
Improved image backup performance
Windows Backup API support (tested backup and restore with Microsoft SQL, tested backup with Microsoft Exchange and Hyper V)
File backups and restores use the change block data from the change block tracking driver now (you can install the beta client over a CBT client and this will work)
Define which volumes need to be snapshotted together (snapshot groups)
Changes with server 2.1.3 beta
Prioritize web interface requests
Proper error handling when VHD file gets too large (>2TB)
Improve logging on VHD file read failures
Set shouldBackoff and hasTimeoutError after SYSVOL/ESP backup fails
Error message about 8dot3 name generation on Windows
Associate virtual clients with server connections
Fix file restore with id offset
Fix archiving in combination with groups
Changes with client 2.1.3 beta
Use O_NOATIME for opening files for backup on Linux
Fix keeping files with virtual clients
Fix async index race condition
Fixes for file keep options for backup directories; fix for resetting it from command line
Fix CBT and snapshot deletion with image snapshot groups
Fix timeout issue with connection encryption
Automatically find postgresql data directory
Fix backup scripts installation via make install
Parameter to script list if backup is a full backup
Insert directory into tar stream if it does not exist yet to prevent errors on server
Delete old virtual client if virtual client gets renamed
Fix deletion of backup paths of virtual clients
Avoid seeking forwards in pipe file in tar streams
Do not use backupid offset if there are multiple connections to server caused by virtual client
Virtual client parameter for browsing and restoring file backups via command line client
Associate virtual clients with server connections
New scripts for incremental backup and restore of MySQL/MariaDB with XtraBackup
Upgrade process
As always: Replace the executables (via the installers) and the database of the server/client will be updated on first running it.
Place the files from the update directory into C:\Program Files\UrBackupServer\urbackup or /var/urbackup to auto-update clients. Disable Download client from update server in the server settings to prevent the server from downloading the current version.
Stop the UrBackup server, restore C:\Program Files\UrBackupServer\urbackup or /var/urbackup from a backup before upgrade and then install the previous version over the beta release.
I also just failed to build this in a FreeNAS (9.10.1 stable) jail.
This is the end of the output;
urbackupserver/cmdline_preprocessor.cpp:462:16: error: use of undeclared identifier ‘RLIMIT_NICE’
if (setrlimit(RLIMIT_NICE, &limit) != 0) {
^
1 error generated.
*** Error code 1
Hi AckRite, Client groups are just collections of specific settings for groups of machines. So you might have a group for super super important machines and you back those up hourly with full dailies and then archive the full backups for 2 years.
Then you might have another group for random machines that get very little use and you only back those up every quarter.
Or maybe you have some machines you want image backups for and others that you just want file. Well, groups lets you do that.
Super handy and something I am really pleased to see as part of the solution.
Oh, and also you add new client groups from the Server “Settings” interface.
Just wondering, will the new “Snapshot Together” feature allow me to create 1 VHD of all the volumes on the machine and then power up the VHD in Hyper-V to run virtually?
On ubuntu i get stuck on indexing (got 2 client+ the server has a client)
it basically loop on this:
maybe i did something bad, i just started using urbackup, but did a full and a few inc and it was working fine before updating to beta
client :
2016-10-17 19:59:34: New channel: Number of Channels: 1
2016-10-17 19:59:40: Client timeout in ClientConnector::Run
2016-10-17 19:59:40: SERVICE_COMMANDS finished
2016-10-17 19:59:43: Started connection to SERVICE_COMMANDS
2016-10-17 19:59:53: Client timeout in ClientConnector::Run
2016-10-17 19:59:53: SERVICE_COMMANDS finished
2016-10-17 20:00:44: Client timeout in ClientConnector::Run - Channel (ping timeout)
2016-10-17 20:00:44: SERVICE_COMMANDS finished
server:
2016-10-17 20:02:01: Timeout: Getting index log data from client failed
2016-10-17 20:02:01: Connecting to target service…
2016-10-17 20:02:01: Established internet connection. Service=0
2016-10-17 20:02:01: Authed+capa for client ‘pascalou’ (token auth) - 1 spare connections
2016-10-17 20:02:04: Connection broken: Error sending ‘running’ (2) ping to client
i scrapped the update and reinstalled 2.0.36 , no more issues.
there were hostnames and i think auth keys in the logs, hence why i didn’t pasted everything.
is there an irc channel ?
can i keep the downloaded data (the full take a day) and switch versions (the doc says to scrap all the urbackup data folder)?
Notice the uppercase differences on volumes letters …
Server’s “btrfs sub list -q /media/urbackup/” | grep MY_CLIENT
ID 1216 gen 21029 top level 5 parent_uuid d755f7a8-559f-4e49-a534-0d57c205c312 uuid 5f61cfa6-a31d-2549-aa9f-259ff717bd9e path backups/SV217/161019-2319_Image_E
ID 1219 gen 19870 top level 5 parent_uuid - uuid d0ae9366-38a2-1047-a008-56c9e57ccd6f path backups/SV217/161019-2320_Image_SYSVOL
ID 1224 gen 21079 top level 5 parent_uuid d3ccd534-5dcc-6b46-9d25-83ba457dd69a uuid 4560b136-cf3f-e74c-8321-146ae8f1ba8d path backups/SV217/161019-2346_Image_c
ID 1232 gen 20474 top level 5 parent_uuid - uuid 7cf8076f-9cd1-ee43-b6be-dfd692f8bbde path backups/SV217/161020-0438_Image_SYSVOL
ID 1234 gen 21235 top level 5 parent_uuid 172264b6-bce2-2845-b544-45e81b10a6a8 uuid 1648df8b-3f8a-b94b-a9e0-ee0f3cd3fdb2 path backups/SV217/161020-0449_Image_C
ID 1235 gen 21237 top level 5 parent_uuid 3ec47c54-b57d-1f4f-bab3-186d1656e38d uuid 4841f5c0-8949-b941-998d-4499b512426e path backups/SV217/161020-0450_Image_e
ID 1240 gen 21054 top level 5 parent_uuid 5f61cfa6-a31d-2549-aa9f-259ff717bd9e uuid 26ef3ab2-cf68-9645-9d02-0a58543c95cf path backups/SV217/161021-0400_Image_E
ID 1245 gen 21078 top level 5 parent_uuid - uuid 571e0d54-cb86-3f49-8648-28b107beb250 path backups/SV217/161021-0401_Image_SYSVOL
ID 1255 gen 21203 top level 5 parent_uuid 4560b136-cf3f-e74c-8321-146ae8f1ba8d uuid f2842f08-7e69-5b42-a25a-9b27ccb144ea path backups/SV217/161021-0413_Image_c
ID 1262 gen 21234 top level 5 parent_uuid - uuid 691f0ea6-7fe2-b34e-9e74-1317f8364bb0 path backups/SV217/161021-0512_Image_SYSVOL
ID 1263 gen 21291 top level 5 parent_uuid 1648df8b-3f8a-b94b-a9e0-ee0f3cd3fdb2 uuid 3686461a-7576-e94a-979e-461b5821617a path backups/SV217/161021-0522_Image_C
ID 1264 gen 21248 top level 5 parent_uuid 4841f5c0-8949-b941-998d-4499b512426e uuid da70086b-3dbe-694e-9630-6ffe463dcf0a path backups/SV217/161021-0523_Image_e
More information : server 2.0.36 updated to 2.1.3 , client updated from 2.0.37-cbt to 2.1.3
Another client with 3 volumes , C: D: and E:
Since update to 2.1.3, Volume D: is backed up normally (ie with cbt) and viewed as D: as before (uppercase)
But volumes C: and D: are now backed up as if they were new volumes, and they are viewed as c: and d: (lowercase vs uppercase …)
Does somebody have the same problem or succeed to reproduce it ?
It seems to be ok for fresh clients (added since 2.1.3), but always with a mix of lowercase / uppercase volumes names when there is more than one …
Backup jobs are still flipping with lowercase / uppercase volumes letters, even with a fresh client.
For example, here are three backups of client with 2 volumes C: and E:
First backup set (OK : initial backup, without CBT)
Thanks for reporting the issue. Will fix it. Should not be too hard. It seems it just saves the image backup letter in two different ways into the database…
