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