Server 2.5.9 beta (updated x3)

aliera · June 13, 2020, 8:55am

I’ve been doing quite a bit testing and maybe there is some minor inconsistency with the new settings handling:

1.) The “Archive”-settings default to custom settings (no inheritance) while other settings default to “use settings from group”:

expected:

Maybe there is a reason for that and its not a bug.

2.) On config page “Alarms” only the first field is inherited. All others don’t show the new settings button.

Not sure, whether on purpose or not yet implemented.

uroni · June 13, 2020, 11:45am

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…

aliera · June 13, 2020, 12:10pm

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

kattivius · June 15, 2020, 10:48am

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.

aliera · June 19, 2020, 5:26pm

Have a look at the docker file:

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.

aliera · June 19, 2020, 6:06pm

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.

aliera · June 19, 2020, 6:49pm

possible solution(?):
add…

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

on line 836 in server_cleanup.cpp:

github.com

uroni/urbackup_backend/blob/2319ebce419bc3e3241536fc66c4787ab52a22ec/urbackupserver/server_cleanup.cpp#L836


		{
			b = false;
		}
		if (!deleteAndTruncateFile(logid, path + ".mbr"))
		{
			if (os_get_file_type(os_file_prefix(path + ".mbr")) & EFileType_File)
			{
				b = false;
			}
		}
		deleteAndTruncateFile(logid, path + ".cbitmap");
		deleteAndTruncateFile(logid, path + ".sync");

		if (b && ExtractFileName(ExtractFilePath(path)) != clientname)
		{
			b = os_remove_dir(os_file_prefix(ExtractFilePath(path)));
		}

		return b;
	}
	else

uroni · June 20, 2020, 1:34pm

Yupp. Will add.

aliera · June 20, 2020, 7:32pm

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:

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

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:

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.

uroni · June 23, 2020, 5:35pm

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.

aliera · June 24, 2020, 11:49am

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.

Dmitrius7 · June 25, 2020, 9:11am

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

aliera · June 25, 2020, 8:37pm

I’ve created a feature request:

tarakesh · June 29, 2020, 12:10am

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

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.

aliera · July 1, 2020, 8:08pm

I’d try to get up-to-date packages from the Debian 11 (Bullseye) testing repo:

Debian 11 contains libc6 version 2.30-8.

Further reading:

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.

aliera · July 1, 2020, 8:22pm

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

DaF_CaV · July 1, 2020, 11:53pm

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.

Don_Wright · July 2, 2020, 6:10am

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.

uroni · July 2, 2020, 2:51pm

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.

aliera · July 6, 2020, 1:00pm

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?