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.
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.
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.
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:
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:
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.
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.
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
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.
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?