Server 2.5.9 beta (updated x3)

It’s the switch for all settings (since alert settings are customizable it is internally a single setting). Maybe I’ll add a separator or something to make that more clear. And maybe have the single settings have switches in a future version but that is a lot of work…

Ah, ok, makes sense. Thanks for your feedback!

Fantastic.
Question:
I installed Urbackup via docker-compose (uroni/urbackup-server) from hub.docker.com.
I am fairly new on dockers.
How can I update the stack?
My urbackup client is V. 2.4.10
Server: (I dont know how to check. Any help, is welcome)
Thanks for your feedback.

Have a look at the docker file:
https://hub.docker.com/r/uroni/urbackup-server/dockerfile

VERSION=2.4.12
ARCH=amd64
FILE_SUBDIR=/
FILE urbackup-server_${VERSION}_${ARCH}.deb

Therefore…

URL https://hndl.urbackup.org/Server/${VERSION}/${FILE_SUBDIR}${FILE}

resolves to:

https://hndl.urbackup.org/Server/2.4.12/urbackup-server_2.4.12_amd64.deb

I’d try replacing URL with the beta:

https://beta.urbackup.org/Server/2.5.9%20beta/urbackup-server_2.5.9_amd64.deb

This is just meant as a starting point. Have not tested the Urbackup Docker Container myself.

Follow up:

Server 2.5.9 beta now does delete most of the image files except “*.raw.bitmap”. When hitting “Delete now” from the GUI, an error message gets shown but no error is found in the logs.

Files successfully deleted when hitting “Delete now”:
*.raw
*.raw.cbitmap
*.raw.hash
*.raw.mbr
*.raw.sync

Remaining file:
*.raw.bitmap

Log when hitting “Delete now” for another time:


2020-06-19 20:01:08: Deleting image backup ( id=6, path=D:\Backup\client1[N]\200619-1928_Image_N\Image_N_200619-1928.raw ) …
2020-06-19 20:01:08: WARNING: Deleting D:\Backup\client1[N]\200619-1928_Image_N\Image_N_200619-1928.raw failed. Das System kann die angegebene Datei nicht finden. (code: 2)
2020-06-19 20:01:08: WARNING: Deleting D:\Backup\client1[N]\200619-1928_Image_N\Image_N_200619-1928.raw.hash failed. Das System kann die angegebene Datei nicht finden. (code: 2)
2020-06-19 20:01:08: WARNING: Deleting D:\Backup\client1[N]\200619-1928_Image_N\Image_N_200619-1928.raw.mbr failed. Das System kann die angegebene Datei nicht finden. (code: 2)
2020-06-19 20:01:08: WARNING: Deleting D:\Backup\client1[N]\200619-1928_Image_N\Image_N_200619-1928.raw.cbitmap failed. Das System kann die angegebene Datei nicht finden. (code: 2)
2020-06-19 20:01:08: WARNING: Deleting D:\Backup\client1[N]\200619-1928_Image_N\Image_N_200619-1928.raw.sync failed. Das System kann die angegebene Datei nicht finden. (code: 2)
2020-06-19 20:01:08: Deleting image backup failed.


Workaround: running ‘remove_unknown.bat’:


2020-06-19 20:04:17: Removing unknown for client “client1[N]”
2020-06-19 20:04:17: WARNING: Image backup [id=6 path=D:\Backup\client1[N]\200619-1928_Image_N\Image_N_200619-1928.raw clientname=client1[N]] does not exist. Deleting it from the database.


possible solution(?):
add…

deleteAndTruncateFile(logid, path + “.bitmap”);

on line 836 in server_cleanup.cpp:

Yupp. Will add.

After some testing, there might be some more bugs in beta server 2.5.9 and client 2.5.3:

Client 2.5.3 beta:


  1. New config icons are missing, thus it is not possible to differentiate between config source:

Tested on OS:
Windows 10 Pro 1909
Windows Server 2019

Used Installers:
UrBackup Client 2.5.3 beta(x64).msi
UrBackup Client 2.5.3 beta.exe


  1. Shadow Copies on Windows Client get deleted after file based backup (that is expected behaviour).
    But after an image backup, the Shadow Copies remain on the Client.
    Tested via ‘vssadmin list shadows’.
    I’d expect that Shadow Copies would be deleted after every backup, indifferent whether file or image backup.
    Is this on purpose?

Server 2.5.9 beta:

  1. Delete button on most recent file backup is missing:

The delete button is only missing on the most recent file backup, not on image backups.

Thanks. Probably missing files. Will look into this…

Could you perhaps create a client debug log from such a client backup and send/post that? Thanks!

That was always the case. It would have to perform a full backup if the last backup is deleted, so this is prevented.

Seems as if the shadowcopy only doesn’t get deleted when doing an image backup of a virtual client. Compare the following log excerpts: First one is when using the “main” client, second one is using a “virtual” client. Other settings are equal. Full log: debug_pseud.log (652.3 KB)

Image backup directly using main client:


2020-06-24 10:05:15: Sending image done
2020-06-24 10:05:15: Deleting shadowcopy for path “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8” -2
2020-06-24 10:05:15: ClientService cmd: STATUS#pw=nyZLM6kdo0x2RVNQGtCLMyOKxAKyQ2
2020-06-24 10:05:16: ClientService cmd: STATUS#pw=nyZLM6kdo0x2RVNQGtCLMyOKxAKyQ2
2020-06-24 10:05:17: Number of Writers: 11
2020-06-24 10:05:17: Writer Task Scheduler Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer VSS Metadata Store Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer Performance Counters Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer System Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer Microsoft Hyper-V VSS Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer ASR Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer Dedup Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer Registry Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer WMI Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer COM+ REGDB Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Writer Shadow Copy Optimization Writer has failure state VSS_WS_STABLE with error S_OK.
2020-06-24 10:05:17: Deleting Shadowcopy for dir “G:”
2020-06-24 10:05:17: Removing running process (1) id 6 server_id 6 token 9NH8KVQH3IAbATTKVyah action 4


Image backup using virtual client:


2020-06-24 10:28:45: Sending image done
2020-06-24 10:28:45: Removing running process (1) id 6 server_id 7 token 9NH8KVQH3IAbATTKVyah1 action 4


Main client: Deleting shadowcopy works on all backup types (full or incremental file backup, full or incremental image backup)

Virtual client: Deleting shadowcopy works only on file backups (full or incremental file backup) but not on image backups (full or incremental image backup)


Ah ok. Good to know that it is on purpose. Haven’t noticed it before. This might have the side effect, that it is not possible to clear all file backups, except removing the entire client. That might be inconvenient, e.g. when image backups exists as well:

Because this isn’t a genuine issue of the current beta, this might be rather a feature request.

Maybe this is inappropriate here, but I vote for this feature request. It would be great to be able to delete all file backups.

I’ve created a feature request:

rather big of a problem here.
Debian 10 seems not compatible with the latest version.
Saying installed libc6 is too old. but you wont get any newer one for a standard debian 10 :frowning:

dpkg -i urbackup-server_2.5.9_amd64.deb
(Lese Datenbank … 121933 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von urbackup-server_2.5.9_amd64.deb …
Entpacken von urbackup-server (2.5.9.0) über (2.4.12.0-1) …
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von urbackup-server:
urbackup-server hängt ab von libc6 (>= 2.29); aber:
Version von libc6:amd64 auf dem System ist 2.28-10.
urbackup-server hängt ab von libgcc-s1 (>= 4.2); aber:
Paket libgcc-s1 ist nicht installiert.

cat /etc/debian_version
10.4

This has been brought up a couple of times now for the 2.5.x branch but was never adressed.

I’d try to get up-to-date packages from the Debian 11 (Bullseye) testing repo:
https://packages.debian.org/bullseye/libc6
Debian 11 contains libc6 version 2.30-8.

Further reading:
https://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version
https://we.riseup.net/debian/installing-testing-packages-on-stable

Of course it would be nice if the current UrBackup beta would be compatible with rather outdated packages contained in Debian 10. On the other hand, it is quite common for beta versions to depend on current up-to-date packages.

I’ve come across another unexpected behaviour in Server 2.5.9 beta:
The two most recent file backups get always archived although no archive config is set. This happens every hour when the archive function runs. Odd: The archive countdown is negative like “Will stop being archived in -26 minutes”.

  • happens to incremental as well as full file backups
  • image backups not affected

log:


2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Did not find backup suitable for archiving with backup_type=0 image=false letter=
2020-07-01 20:29:46: Archived backup with id=21 image=false letter= for 0 seconds
2020-07-01 20:29:46: Archived backup with id=19 image=false letter= for 0 seconds
2020-07-01 20:29:46: Archived backup with id=25 image=false letter= for 0 seconds
2020-07-01 20:29:46: Archived backup with id=24 image=false letter= for 0 seconds


this is not recomendable at all on any production scenario! if we are making backups, that means we are dealing with sensitive data, so we are looking for a STABLE server. If it is not in debian backports, just use another distro (i don’t like ubuntu but people are free to choose). I prefer debian or turnleylinux for must servers setups.

DaF_CaV: If you have difficulty using a released version of UrBackup, please start a new message in the proper forum category. This is the “Testing” forum for unreleased software under development. As you mentioned Debian I would say it is more like Sid than Debian Testing. Breakage is expected for software downloaded from links in these messages.

Best would be compiling the server/client yourself anyway. It should not be hard, and that way debugging is really easy if there is a problem.

I was thinking about submitting a pull request for some of the bugs mentioned before or document them as issues. The dev-branch on github is a bit behind (https://github.com/uroni/urbackup_backend/tree/dev).
For issues on testing version, is it best to just use this forum or the issue tracker at urbackup.atlassian.net?

Just pushed an up-to-date version to github. Pull requests are welcome of course. As long as it is only a few issues, the forum suffices, I guess.

Open issues:

  • Missing icons for the settings in tray icon GUI (probably will fix that today)
  • Archive/archive settings issues

Thanks for the help!