October 17Oct 17 Moin, hab jetzt gestern mal mit den Scripten gespielt und meinen einen Job gestartet Server Startet er wartet bis alles erreichbar ist und legt dann los (siehe LOG unten)Jetzt frag ich mich ob das normal ist das es so lange dauert? meine HDD am Unraid war gut am Arbeiten, netzwerk traffic ging heute früh um 5 uhr erst los aber eigentlich in die falsche Richtung .. Synology hat ausgehen Traffic und mein Unraid eingehend (HDD´s im Unraid machen nix, nur die vom Synology Lesen) Hab ich das Backup noch nicht verstanden ? LOG 2026-10-16 18:36:27 INFO Active Borg binary: /usr/local/bin/borg 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO BACKUP START 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO Job: Daten 2026-10-16 18:36:28 INFO Job ID: fc3a6297-828c-4255-92d4-0bc8ff7e093f 2026-10-16 18:36:28 INFO Date: 2026-10-16_18-36-27 2026-10-16 18:36:28 INFO Log: /mnt/user/borg-backup-ui/logs/BBUI-Daten_smb_fc3a6297-828c-4255-92d4-0bc8ff7e093f--2026-10-16_18-36-27.log 2026-10-16 18:36:28 INFO 2026-10-16 18:36:28 INFO Effective configuration: 2026-10-16 18:36:28 INFO Repository: /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a/daten 2026-10-16 18:36:28 INFO Compression: lz4 2026-10-16 18:36:28 INFO Exclusions: none 2026-10-16 18:36:28 INFO Retention: --keep-hourly 0 --keep-daily 1 --keep-weekly 2 --keep-monthly 6 --keep-yearly 3 2026-10-16 18:36:28 INFO Log-Dir: /mnt/user/borg-backup-ui/logs (30 days) 2026-10-16 18:36:28 INFO Cache: /mnt/user/borg-backup-ui/cache/smb_daten 2026-10-16 18:36:28 INFO Borg security: /boot/config/borg-backup/borg-security 2026-10-16 18:36:28 INFO 2026-10-16 18:36:28 INFO Created lock file (PID: 2705587) 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO PHASE: PRE SCRIPT 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO Script: Großer Server WoL (timeout: 750 seconds) 2026-10-16 18:40:47 INFO [pre script] [INFO] Prüfe Proxmox... 2026-10-16 18:40:47 INFO [pre script] [INFO] Proxmox ist aus -> Wake-on-LAN 2026-10-16 18:40:47 INFO [pre script] [INFO] Wake-on-LAN gesendet. 2026-10-16 18:40:47 INFO [pre script] [INFO] Warte auf Proxmox... 2026-10-16 18:40:47 INFO [pre script] [INFO] Proxmox ist erreichbar. 2026-10-16 18:40:47 INFO [pre script] [INFO] Warte auf Synology 192.168.1.6... 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (3/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (6/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (9/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (12/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology ist per Ping erreichbar. 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology antwortet auf Ping. 2026-10-16 18:40:47 INFO [pre script] [INFO] Warte weitere 120 Sekunden auf DSM und SMB... 2026-10-16 18:40:47 INFO [pre script] [INFO] Zusätzliche Wartezeit beendet. 2026-10-16 18:40:47 INFO [pre script] [INFO] Proxmox und Synology sind bereit. 2026-10-16 18:40:47 INFO [pre script] [INFO] Pre-Script erfolgreich beendet. 2026-10-16 18:40:47 INFO [pre script] [INFO] Borg Backup kann starten. 2026-10-16 18:40:47 INFO pre script finished: success (exit 0; 259.273 seconds) 2026-10-16 18:40:47 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:47 INFO SMB mount succeeded: //192.168.1.6/SicherungNUCi5 -> /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a 2026-10-16 18:40:47 INFO Parity check enabled (ABORT_ON_PARITY_CHECK=true) 2026-10-16 18:40:47 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:47 INFO PHASE 1: VALIDATION 2026-10-16 18:40:47 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:47 INFO Validating prerequisites... 2026-10-16 18:40:47 INFO [1/3] Checking backup paths... 2026-10-16 18:40:47 INFO OK - 11/11 paths found 2026-10-16 18:40:47 INFO [2/3] Checking Borg Backup installation... 2026-10-16 18:40:48 INFO OK - borg 1.4.5 2026-10-16 18:40:48 INFO [3/3] Checking cache directory... 2026-10-16 18:40:48 INFO OK - /mnt/user/borg-backup-ui/cache/smb_daten 2026-10-16 18:40:48 INFO Validation completed successfully 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO PHASE 2: PREPARATION 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO Removing logs older than 30 days... 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO PHASE 3: BORG BACKUP (CREATE) 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO Repository: /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a/daten 2026-10-16 18:40:48 INFO Backup paths: /mnt/user/3D Printing /mnt/user/3D-Drucker_und_FPV /mnt/user/Aufnahme /mnt/user/Daten /mnt/user/Downloads /mnt/user/Filme /mnt/user/FotoBearbeitung /mnt/user/Installation /mnt/user/Iphone Sync /mnt/user/Musik /mnt/user/Sonstiges 2026-10-16 18:40:48 INFO Excluded paths: none 2026-10-16 18:40:48 INFO Exclusion markers: none 2026-10-16 18:40:48 INFO Performance: Compression=lz4 2026-10-16 18:40:48 INFO File activity output: disabled 2026-10-16 18:40:48 INFO Cache: /mnt/user/borg-backup-ui/cache/smb_daten 2026-10-16 18:40:48 INFO 2026-10-16 18:40:48 INFO Borg create starting... (11 paths, compression=lz4) 2026-10-17 05:12:07 INFO ------------------------------------------------------------------------------ 2026-10-17 05:12:07 INFO Repository: /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a/daten 2026-10-17 05:12:07 INFO Archive name: daten-backup-2026-10-16_18-40-49 2026-10-17 05:12:07 INFO Archive fingerprint: 8b6f225b3fb7a5fb05b336c240d6c461641e64485151006b78d971773efed8f0 2026-10-17 05:12:07 INFO Time (start): Fri, 2026-10-16 18:40:50 2026-10-17 05:12:07 INFO Time (end): Sat, 2026-10-17 05:12:01 2026-10-17 05:12:07 INFO Duration: 10 hours 31 minutes 10.79 seconds 2026-10-17 05:12:07 INFO Number of files: 220396 2026-10-17 05:12:07 INFO Utilization of max. archive size: 0% 2026-10-17 05:12:07 INFO ------------------------------------------------------------------------------ 2026-10-17 05:12:07 INFO Original size Compressed size Deduplicated size 2026-10-17 05:12:07 INFO This archive: 3.21 TB 2.98 TB 272.93 GB 2026-10-17 05:12:07 INFO All archives: 9.09 TB 8.41 TB 2.81 TB 2026-10-17 05:12:07 INFO Unique chunks Total chunks 2026-10-17 05:12:07 INFO Chunk index: 1265779 4283449 2026-10-17 05:12:07 INFO ------------------------------------------------------------------------------ 2026-10-17 05:12:07 INFO terminating with success status, rc 0 2026-10-17 05:12:07 INFO Borg create succeeded 2026-10-17 05:12:07 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 05:12:07 INFO PHASE 4: BORG MAINTENANCE (Prune, Compact, Check) 2026-10-17 05:12:07 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 05:12:07 INFO Maintenance step: prune 2026-10-17 05:12:07 INFO Borg prune: archive filter daten-backup-*; --keep-hourly 0 --keep-daily 1 --keep-weekly 2 --keep-monthly 6 --keep-yearly 3 2026-10-17 05:12:09 INFO Repository contains 3 normal archives and 1 checkpoint archives. 2026-10-17 05:12:09 INFO Applying rules to the matching 3 archives and 1 checkpoints... 2026-10-17 05:12:09 INFO Keeping 3 archives and 0 checkpoints, pruning 0 archives and 1 checkpoints. 2026-10-17 05:12:09 INFO Keeping archive (rule: daily #1): daten-backup-2026-10-16_18-40-49 Fri, 2026-10-16 18:40:50 [8b6f225b3fb7a5fb05b336c240d6c461641e64485151006b78d971773efed8f0] 2026-10-17 05:12:11 INFO Pruning archive (1/1): daten-backup-2026-09-19_23-04-59.checkpoint Sat, 2026-09-19 23:05:00 [732f28888da2e92e4dab862919bb94e7ee26441ccf19abd59d0927af5eaa37bf] 2026-10-17 05:12:11 INFO Keeping archive (rule: weekly #1): daten-backup-2026-08-17_19-34-21 Mon, 2026-08-17 19:34:23 [ccd64c05b398906de710b28c87466a3111cb16e561c03c9f3ea2930b9b378b3d] 2026-10-17 05:12:11 INFO Keeping archive (rule: weekly #2): daten-backup-2026-08-16_13-25-30 Sun, 2026-08-16 13:25:30 [3b0f0d8bd7d71d1713362d6c07875980b37215c7bd534b3386d4d7f205638dec] 2026-10-17 05:12:12 INFO terminating with success status, rc 0 2026-10-17 05:12:13 INFO Borg prune succeeded 2026-10-17 05:12:13 INFO Maintenance step: compact 2026-10-17 05:12:13 INFO Borg compact: reclaiming unused space... 2026-10-17 05:12:16 INFO compaction freed about 488.51 kB repository space. 2026-10-17 05:12:17 INFO terminating with success status, rc 0 2026-10-17 05:12:17 INFO Borg compact succeeded 2026-10-17 05:12:17 INFO Maintenance step: check 2026-10-17 05:12:17 INFO Borg check: checking repository integrity (last check 999 days ago)... Edited October 17Oct 17 by Cupra-Bo
October 17Oct 17 Author 41 minutes ago, Cupra-Bo said:Moin, hab jetzt gestern mal mit den Scripten gespielt und meinen einen Job gestartet Server Startet er wartet bis alles erreichbar ist und legt dann los (siehe LOG unten)Jetzt frag ich mich ob das normal ist das es so lange dauert? meine HDD am Unraid war gut am Arbeiten, netzwerk traffic ging heute früh um 5 uhr erst los aber eigentlich in die falsche Richtung .. Synology hat ausgehen Traffic und mein Unraid eingehend (HDD´s im Unraid machen nix, nur die vom Synology Lesen) Hab ich das Backup noch nicht verstanden ? LOG2026-10-16 18:36:27 INFO Active Borg binary: /usr/local/bin/borg 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO BACKUP START 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO Job: Daten 2026-10-16 18:36:28 INFO Job ID: fc3a6297-828c-4255-92d4-0bc8ff7e093f 2026-10-16 18:36:28 INFO Date: 2026-10-16_18-36-27 2026-10-16 18:36:28 INFO Log: /mnt/user/borg-backup-ui/logs/BBUI-Daten_smb_fc3a6297-828c-4255-92d4-0bc8ff7e093f--2026-10-16_18-36-27.log 2026-10-16 18:36:28 INFO 2026-10-16 18:36:28 INFO Effective configuration: 2026-10-16 18:36:28 INFO Repository: /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a/daten 2026-10-16 18:36:28 INFO Compression: lz4 2026-10-16 18:36:28 INFO Exclusions: none 2026-10-16 18:36:28 INFO Retention: --keep-hourly 0 --keep-daily 1 --keep-weekly 2 --keep-monthly 6 --keep-yearly 3 2026-10-16 18:36:28 INFO Log-Dir: /mnt/user/borg-backup-ui/logs (30 days) 2026-10-16 18:36:28 INFO Cache: /mnt/user/borg-backup-ui/cache/smb_daten 2026-10-16 18:36:28 INFO Borg security: /boot/config/borg-backup/borg-security 2026-10-16 18:36:28 INFO 2026-10-16 18:36:28 INFO Created lock file (PID: 2705587) 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO PHASE: PRE SCRIPT 2026-10-16 18:36:28 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:36:28 INFO Script: Großer Server WoL (timeout: 750 seconds) 2026-10-16 18:40:47 INFO [pre script] [INFO] Prüfe Proxmox... 2026-10-16 18:40:47 INFO [pre script] [INFO] Proxmox ist aus -> Wake-on-LAN 2026-10-16 18:40:47 INFO [pre script] [INFO] Wake-on-LAN gesendet. 2026-10-16 18:40:47 INFO [pre script] [INFO] Warte auf Proxmox... 2026-10-16 18:40:47 INFO [pre script] [INFO] Proxmox ist erreichbar. 2026-10-16 18:40:47 INFO [pre script] [INFO] Warte auf Synology 192.168.1.6... 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (3/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (6/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (9/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology noch nicht erreichbar... (12/60) 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology ist per Ping erreichbar. 2026-10-16 18:40:47 INFO [pre script] [INFO] Synology antwortet auf Ping. 2026-10-16 18:40:47 INFO [pre script] [INFO] Warte weitere 120 Sekunden auf DSM und SMB... 2026-10-16 18:40:47 INFO [pre script] [INFO] Zusätzliche Wartezeit beendet. 2026-10-16 18:40:47 INFO [pre script] [INFO] Proxmox und Synology sind bereit. 2026-10-16 18:40:47 INFO [pre script] [INFO] Pre-Script erfolgreich beendet. 2026-10-16 18:40:47 INFO [pre script] [INFO] Borg Backup kann starten. 2026-10-16 18:40:47 INFO pre script finished: success (exit 0; 259.273 seconds) 2026-10-16 18:40:47 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:47 INFO SMB mount succeeded: //192.168.1.6/SicherungNUCi5 -> /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a 2026-10-16 18:40:47 INFO Parity check enabled (ABORT_ON_PARITY_CHECK=true) 2026-10-16 18:40:47 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:47 INFO PHASE 1: VALIDATION 2026-10-16 18:40:47 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:47 INFO Validating prerequisites... 2026-10-16 18:40:47 INFO [1/3] Checking backup paths... 2026-10-16 18:40:47 INFO OK - 11/11 paths found 2026-10-16 18:40:47 INFO [2/3] Checking Borg Backup installation... 2026-10-16 18:40:48 INFO OK - borg 1.4.5 2026-10-16 18:40:48 INFO [3/3] Checking cache directory... 2026-10-16 18:40:48 INFO OK - /mnt/user/borg-backup-ui/cache/smb_daten 2026-10-16 18:40:48 INFO Validation completed successfully 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO PHASE 2: PREPARATION 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO Removing logs older than 30 days... 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO PHASE 3: BORG BACKUP (CREATE) 2026-10-16 18:40:48 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-16 18:40:48 INFO Repository: /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a/daten 2026-10-16 18:40:48 INFO Backup paths: /mnt/user/3D Printing /mnt/user/3D-Drucker_und_FPV /mnt/user/Aufnahme /mnt/user/Daten /mnt/user/Downloads /mnt/user/Filme /mnt/user/FotoBearbeitung /mnt/user/Installation /mnt/user/Iphone Sync /mnt/user/Musik /mnt/user/Sonstiges 2026-10-16 18:40:48 INFO Excluded paths: none 2026-10-16 18:40:48 INFO Exclusion markers: none 2026-10-16 18:40:48 INFO Performance: Compression=lz4 2026-10-16 18:40:48 INFO File activity output: disabled 2026-10-16 18:40:48 INFO Cache: /mnt/user/borg-backup-ui/cache/smb_daten 2026-10-16 18:40:48 INFO 2026-10-16 18:40:48 INFO Borg create starting... (11 paths, compression=lz4) 2026-10-17 05:12:07 INFO ------------------------------------------------------------------------------ 2026-10-17 05:12:07 INFO Repository: /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a/daten 2026-10-17 05:12:07 INFO Archive name: daten-backup-2026-10-16_18-40-49 2026-10-17 05:12:07 INFO Archive fingerprint: 8b6f225b3fb7a5fb05b336c240d6c461641e64485151006b78d971773efed8f0 2026-10-17 05:12:07 INFO Time (start): Fri, 2026-10-16 18:40:50 2026-10-17 05:12:07 INFO Time (end): Sat, 2026-10-17 05:12:01 2026-10-17 05:12:07 INFO Duration: 10 hours 31 minutes 10.79 seconds 2026-10-17 05:12:07 INFO Number of files: 220396 2026-10-17 05:12:07 INFO Utilization of max. archive size: 0% 2026-10-17 05:12:07 INFO ------------------------------------------------------------------------------ 2026-10-17 05:12:07 INFO Original size Compressed size Deduplicated size 2026-10-17 05:12:07 INFO This archive: 3.21 TB 2.98 TB 272.93 GB 2026-10-17 05:12:07 INFO All archives: 9.09 TB 8.41 TB 2.81 TB 2026-10-17 05:12:07 INFO Unique chunks Total chunks 2026-10-17 05:12:07 INFO Chunk index: 1265779 4283449 2026-10-17 05:12:07 INFO ------------------------------------------------------------------------------ 2026-10-17 05:12:07 INFO terminating with success status, rc 0 2026-10-17 05:12:07 INFO Borg create succeeded 2026-10-17 05:12:07 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 05:12:07 INFO PHASE 4: BORG MAINTENANCE (Prune, Compact, Check) 2026-10-17 05:12:07 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 05:12:07 INFO Maintenance step: prune 2026-10-17 05:12:07 INFO Borg prune: archive filter daten-backup-*; --keep-hourly 0 --keep-daily 1 --keep-weekly 2 --keep-monthly 6 --keep-yearly 3 2026-10-17 05:12:09 INFO Repository contains 3 normal archives and 1 checkpoint archives. 2026-10-17 05:12:09 INFO Applying rules to the matching 3 archives and 1 checkpoints... 2026-10-17 05:12:09 INFO Keeping 3 archives and 0 checkpoints, pruning 0 archives and 1 checkpoints. 2026-10-17 05:12:09 INFO Keeping archive (rule: daily #1): daten-backup-2026-10-16_18-40-49 Fri, 2026-10-16 18:40:50 [8b6f225b3fb7a5fb05b336c240d6c461641e64485151006b78d971773efed8f0] 2026-10-17 05:12:11 INFO Pruning archive (1/1): daten-backup-2026-09-19_23-04-59.checkpoint Sat, 2026-09-19 23:05:00 [732f28888da2e92e4dab862919bb94e7ee26441ccf19abd59d0927af5eaa37bf] 2026-10-17 05:12:11 INFO Keeping archive (rule: weekly #1): daten-backup-2026-08-17_19-34-21 Mon, 2026-08-17 19:34:23 [ccd64c05b398906de710b28c87466a3111cb16e561c03c9f3ea2930b9b378b3d] 2026-10-17 05:12:11 INFO Keeping archive (rule: weekly #2): daten-backup-2026-08-16_13-25-30 Sun, 2026-08-16 13:25:30 [3b0f0d8bd7d71d1713362d6c07875980b37215c7bd534b3386d4d7f205638dec] 2026-10-17 05:12:12 INFO terminating with success status, rc 0 2026-10-17 05:12:13 INFO Borg prune succeeded 2026-10-17 05:12:13 INFO Maintenance step: compact 2026-10-17 05:12:13 INFO Borg compact: reclaiming unused space... 2026-10-17 05:12:16 INFO compaction freed about 488.51 kB repository space. 2026-10-17 05:12:17 INFO terminating with success status, rc 0 2026-10-17 05:12:17 INFO Borg compact succeeded 2026-10-17 05:12:17 INFO Maintenance step: check 2026-10-17 05:12:17 INFO Borg check: checking repository integrity (last check 999 days ago)...Hallo,erst einmal: Dein Backup hat erfolgreich funktioniert! 😊Das Pre-Script hat Proxmox und die Synology gestartet, anschließend wurden die 11 ausgewählten Verzeichnisse gesichert.Das eigentliche Backup lief von 18:40 Uhr bis 05:12 Uhr, also rund 10,5 Stunden. Bei 3,21 TB Daten, über 220.000 Dateien und einer Sicherung auf HDDs über SMB ist das grundsätzlich nicht ungewöhnlich.Warum läuft der Netzwerkverkehr jetzt in die falsche Richtung?Das ist tatsächlich erklärbar. Um 05:12 Uhr war dein Backup bereits erfolgreich abgeschlossen. Danach hat Borg Backup UI automatisch die Wartung gestartet:Prune: Alte Sicherungen entsprechend deiner Aufbewahrungsregeln bereinigen.Compact: Nicht mehr benötigten Speicher freigeben.Check: Das Backup-Repository auf Fehler überprüfen.Gerade der letzte Punkt dürfte deine Beobachtung erklären.Da dein Repository per SMB auf der Synology liegt, muss Borg für die Integritätsprüfung die gespeicherten Daten von dort lesen. Deshalb sendet die Synology Daten und Unraid empfängt diese. Es wird also nicht versehentlich in die falsche Richtung gesichert.Bei der Größe deines Repositorys von rund 2,81 TB kann diese Prüfung durchaus länger dauern.Was die 10,5 Stunden Backupzeit betrifft: Das ist zunächst plausibel. Ob wir hier noch etwas optimieren können, müssten wir uns anhand deiner Hardware, Netzwerkgeschwindigkeit und der tatsächlichen Datenänderungen anschauen.Ich nehme deinen Fall aber auch als Anregung für Borg Backup UI mit. Wir könnten in der Oberfläche deutlicher zwischen dem eigentlichen Backup und der anschließenden Integritätsprüfung unterscheiden.Eine Frage hätte ich noch: Läuft der Job inzwischen vollständig durch, und was steht nach Borg check in deinem Log?Viele GrüßeThorsten Edited October 17Oct 17 by Thorsten
October 17Oct 17 Hi Thorsten, erst mal Danke für die Erklärung, ich hab den Job dann heute morgen abgebrochen weil ich mir dachte, ich muss das in Paar mehr Jobs aufteilen z.b. Filme muss er nicht ständig Backupen.Frag mich aber auch gerade wie ich die Job Reihenfolge mache, das er Job1 per Script meine Backup Kiste startet danach Job 2-5 macht und Job5 dann die Kiste runterfährt Netzwerk hab ich nur 1000er also Speed gehen gut 100-130 die macht er auch
October 17Oct 17 Author 40 minutes ago, Cupra-Bo said:Hi Thorsten, erst mal Danke für die Erklärung, ich hab den Job dann heute morgen abgebrochen weil ich mir dachte, ich muss das in Paar mehr Jobs aufteilen z.b. Filme muss er nicht ständig Backupen.Frag mich aber auch gerade wie ich die Job Reihenfolge mache, das er Job1 per Script meine Backup Kiste startet danach Job 2-5 macht und Job5 dann die Kiste runterfährt Netzwerk hab ich nur 1000er also Speed gehen gut 100-130 die macht er auch Hi,die Aufteilung in mehrere Jobs finde ich durchaus sinnvoll. Gerade Filme oder andere Daten, die sich selten ändern, müssen nicht unbedingt täglich gesichert werden.Wobei Borg durch die Deduplizierung bei unveränderten Daten normalerweise auch nicht alles erneut übertragen muss. Die Dateien müssen allerdings weiterhin geprüft werden, was natürlich Zeit kostet.Bei deiner Gigabit-Verbindung sind die genannten 100–130 MB/s absolut plausibel. Viel mehr ist über eine einzelne 1-Gbit-Verbindung ohnehin nicht möglich.Was die Reihenfolge der Jobs angeht, sprichst du einen interessanten Punkt an.Aktuell würde ich die Jobs nicht einfach über unterschiedliche Uhrzeiten hintereinander planen. Wenn beispielsweise Job 2 länger läuft als erwartet, könnte Job 3 bereits starten oder die Synology heruntergefahren werden, während noch eine Sicherung läuft.Eigentlich bräuchten wir dafür eine Art Job-Verkettung:Synology bzw. Proxmox einmalig starten.Warten, bis alles erreichbar ist.Job 1 ausführen.Nach dessen Abschluss automatisch Job 2 starten usw.Wenn alle Jobs einschließlich ihrer Wartung abgeschlossen sind, die Backup-Systeme herunterfahren.Das wäre aus meiner Sicht auch eine sinnvolle Erweiterung für Borg Backup UI. Ich werde mir das Thema genauer anschauen.Bis dahin würde ich die Jobs zunächst getrennt einrichten und den automatischen Shutdown nicht fest an den letzten Job koppeln, solange die Reihenfolge nicht zuverlässig sichergestellt ist.Und noch etwas zum ursprünglichen Log: Der Integritätscheck war vermutlich der Grund für den hohen Netzwerkverkehr von der Synology zu Unraid. Dass du diesen abgebrochen hast, bedeutet nicht, dass das zuvor erfolgreich erstellte Backup verloren ist. Die Integritätsprüfung sollte aber später vollständig nachgeholt werden.Viele GrüßeThorsten
October 17Oct 17 Author Hi @Cupra-Bo,ich habe deinen Vorschlag aufgegriffen und dafür Jobgruppen eingebaut.Unter Jobs → Jobgruppen kannst du jetzt vorhandene Backup-Jobs zusammenfassen und ihre Reihenfolge festlegen. Die Gruppe lässt sich manuell oder über einen eigenen Zeitplan starten.Für deinen Fall wäre der Ablauf:Das Pre-Skript des ersten Jobs startet die Backup-Kiste und wartet, bis sie erreichbar ist.Die Jobs werden nacheinander ausgeführt. Der nächste startet erst, wenn der vorherige vollständig abgeschlossen ist – einschließlich Wartung und Post-Skript.Das Post-Skript des letzten Jobs fährt die Backup-Kiste herunter.Die bestehenden Job-Einstellungen und Skripte bleiben erhalten. In der Gruppenansicht siehst du den Fortschritt jedes Jobs und kannst dessen Live-Log oder gespeichertes Log öffnen.Einzelzeitpläne bleiben ebenfalls erhalten. Wenn die Sicherungen ausschließlich über die Gruppe laufen sollen, solltest du diese deaktivieren. Die Oberfläche weist auf zusätzlich aktive Einzelzeitpläne hin.Bei Fehlern kannst du einstellen, ob die Gruppe stoppen oder mit dem nächsten Job fortfahren soll. Wird sie vor dem letzten Job gestoppt, wird dessen Shutdown-Skript nicht ausgeführt. Andere Jobs und Gruppen können weiterhin unabhängig starten; deren Zeitpläne und Shutdown-Skripte musst du entsprechend abstimmen.Die Funktion ist in Version 2026.10.17.1802 enthalten.Viele GrüßeThorsten
October 17Oct 17 Bin gerade noch dabei ein Backup mal durchlaufen zu lassen .. Backup ging sau schnell aber der Rest läuft jetzt schon 9 Stunden :D Synology drückt wieder richtung Unraid :D so recht durchblicken tu ich nicht .. genauer Log wäre hier geil
October 17Oct 17 Author Du sieht doch ein Live Log wo steht er da ?Wenn er bei Check steht dann ließt er einmal das gesamte Archiv also alles nur das aktuelle sondern alle. Das macht er einmal und so oft wie es eingestellt ist per default alle 30 Tage. Ansonsten dauert nach dem Backup nichts lange prune und compact gehen schnell nur Check dauert sehr lange. Und das macht er auf dem System wo das Repository ist. Ansonsten sag mir was dir wo genau fehlt weil alles was Borg liefert landet im Logfile. Edited October 17Oct 17 by Thorsten
October 17Oct 17 Hab noch kein Update gemacht, aber scheinbar passt mein Shutdown Script noch nicht Log 2026-10-17 15:25:10 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 15:25:10 INFO PHASE 4: BORG MAINTENANCE (Prune, Compact, Check) 2026-10-17 15:25:10 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 15:25:10 INFO Maintenance step: prune 2026-10-17 15:25:10 INFO Borg prune: archive filter daten-backup-*; --keep-last 2 2026-10-17 15:25:12 INFO Repository contains 4 normal archives and 0 checkpoint archives. 2026-10-17 15:25:12 INFO Applying rules to the matching 4 archives and 0 checkpoints... 2026-10-17 15:25:12 INFO Keeping 2 archives and 0 checkpoints, pruning 2 archives and 0 checkpoints. 2026-10-17 15:25:12 INFO Keeping archive (rule: secondly #1): daten-backup-2026-10-17_15-05-26 Sat, 2026-10-17 15:05:28 [e85731e0aff4061b6190ec9813ed6102dc10344a859d6bf9eced26f37145a563] 2026-10-17 15:25:12 INFO Keeping archive (rule: secondly #2): daten-backup-2026-10-16_18-40-49 Fri, 2026-10-16 18:40:50 [8b6f225b3fb7a5fb05b336c240d6c461641e64485151006b78d971773efed8f0] 2026-10-17 15:25:18 INFO Pruning archive (1/2): daten-backup-2026-08-17_19-34-21 Mon, 2026-08-17 19:34:23 [ccd64c05b398906de710b28c87466a3111cb16e561c03c9f3ea2930b9b378b3d] 2026-10-17 15:26:07 INFO Pruning archive (2/2): daten-backup-2026-08-16_13-25-30 Sun, 2026-08-16 13:25:30 [3b0f0d8bd7d71d1713362d6c07875980b37215c7bd534b3386d4d7f205638dec] 2026-10-17 15:26:09 INFO terminating with success status, rc 0 2026-10-17 15:26:10 INFO Borg prune succeeded 2026-10-17 15:26:10 INFO Maintenance step: compact 2026-10-17 15:26:10 INFO Borg compact: reclaiming unused space... 2026-10-17 15:27:54 INFO compaction freed about 9.43 GB repository space. 2026-10-17 15:27:54 INFO terminating with success status, rc 0 2026-10-17 15:27:54 INFO Borg compact succeeded 2026-10-17 15:27:54 INFO Maintenance step: check 2026-10-17 15:27:54 INFO Borg check: checking repository integrity (last check 999 days ago)... 2026-10-17 22:15:59 INFO terminating with success status, rc 0 2026-10-17 22:15:59 INFO Borg check succeeded - repository OK 2026-10-17 22:15:59 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 22:15:59 INFO PHASE 5: CLEANUP & COMPLETION 2026-10-17 22:15:59 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 22:16:02 INFO SMB unmount completed: /mnt/borg-backup-ui/smb/SynoProx-smb-180d1a 2026-10-17 22:16:02 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 22:16:02 INFO PHASE: POST SCRIPT 2026-10-17 22:16:02 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 22:16:02 INFO Script: Großen Server Runterfahren (timeout: 300 seconds) 2026-10-17 22:16:02 INFO [post script] /proc/self/fd/5: line 6: [: : integer expected 2026-10-17 22:16:02 INFO [post script] /proc/self/fd/5: line 62: log: command not found 2026-10-17 22:16:02 INFO [post script] /proc/self/fd/5: line 63: log: command not found 2026-10-17 22:16:02 INFO post script finished: failed (exit 127; 0.005 seconds) 2026-10-17 22:16:02 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 22:16:02 INFO Backup job failed (job exit 2) 2026-10-17 22:16:02 INFO Post script failed (exit 127) 2026-10-17 22:16:02 WARNING No mail recipient configured; skipping mail delivery 2026-10-17 22:16:02 INFO Notification event processed (event=backup_failed source=backup_job unraid=True email=False apprise=False apprise_mode=queued apprise_profiles=[]) 2026-10-17 22:16:02 INFO Saved backup status: /mnt/user/borg-backup-ui/status/2026-10-17_22-16-02_Daten_smb_fc3a6297-828c-4255-92d4-0bc8ff7e093f.status 2026-10-17 22:16:02 INFO End: Daten 2026-10-17 22:16:02 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 22:16:02 INFO BACKUP FAILED 2026-10-17 22:16:02 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-10-17 22:16:02 INFO Unraid dashboard widget cache updated (backup finalization)
October 17Oct 17 Author Hi,jetzt haben wir es! 😄Dein neues Log bestätigt eigentlich genau das, was ich schon vermutet hatte.Dein Backup funktioniert einwandfrei! Auch die anschließende Integritätsprüfung wurde erfolgreich abgeschlossen.Schau mal auf die Zeiten:15:25 Uhr: Dein eigentliches Backup ist bereits fertig.15:25–15:27 Uhr: Borg bereinigt alte Archive (Prune) und gibt Speicher frei (Compact).15:27–22:15 Uhr: Borg prüft die Integrität des Backup-Repositories (Check).Die fast sieben Stunden, in denen deine Synology Daten an Unraid sendet, kommen also von der Integritätsprüfung und nicht vom Backup selbst.Warum ist das so?Dein Backup liegt auf der Synology und ist über SMB eingebunden. Borg läuft aber auf Unraid. Wenn Borg jetzt die Integrität des Repositories überprüft, muss es die Daten von der Synology lesen.Deshalb siehst du auf der Synology ausgehenden und auf Unraid eingehenden Netzwerkverkehr. Das ist völlig normal.Die gute Nachricht: Um 22:15 Uhr meldet Borg:Borg check succeeded - repository OKDein Repository hat die Prüfung also bestanden. 👍Muss diese Prüfung jedes Mal laufen?Nein, eine vollständige Integritätsprüfung muss nicht nach jedem Backup durchgeführt werden. Bei größeren Repositories kann sie mehrere Stunden dauern.Ich würde dir empfehlen, den vollständigen Check in Borg Backup UI alle 30 Tage auszuführen. Wichtig ist nur, dass er regelmäßig stattfindet.Jetzt zu deinem Shutdown-Script:Hier haben wir tatsächlich einen Fehler:line 6: [: : integer expected line 62: log: command not found line 63: log: command not found post script finished: failed (exit 127)In Zeile 6 wird vermutlich eine leere Variable als Zahl verglichen. In den Zeilen 62 und 63 verwendest du einen Befehl log, der im Script nicht definiert ist.Deshalb wird der gesamte Job als FAILED angezeigt, obwohl das Backup erfolgreich war.Und noch etwas: Dein Feedback zeigt mir, dass wir die einzelnen Phasen in Borg Backup UI verständlicher darstellen sollten. Gerade bei langen Integritätsprüfungen wäre eine deutlichere Anzeige hilfreich, damit man sofort erkennt, dass das Backup längst abgeschlossen ist und gerade nur noch die Überprüfung läuft.Viele GrüßeThorsten Edited October 17Oct 17 by Thorsten
October 17Oct 17 Author Borg Backup UI 2026.10.17.1802FehlerbehebungenDer Job-Assistent zeigt Zeitplanfelder und die Vorschau des nächsten Starts nur noch bei aktivierter Zeitplanung an. Bei deaktivierter Zeitplanung wird deutlich angezeigt, dass der Job manuell ausgeführt wird. Bereits eingegebene Werte bleiben beim Umschalten erhalten. (#568)VerbesserungenBestehende Backup-Jobs lassen sich in Job-Gruppen nacheinander ausführen – mit eigenen Zeitplänen, festgelegter Reihenfolge, konfigurierbarem Fehlerverhalten und integrierten Logs. Einzelne Jobs behalten ihre Einstellungen, Skripte und Zeitpläne. (#570)Die Gruppenzugehörigkeit wird an den einzelnen Jobs angezeigt und bleibt in Historie und Reports nachvollziehbar. Vollständige Job-Gruppen können zusammen mit ihren Jobs exportiert und importiert werden. (#570)Statusanzeigen für Gruppenläufe werden einheitlich ausgerichtet. Zugehörige Jobs im Dashboard zeigen verlinkte Gruppennamen und Schrittnummern. Die Größe des Log-Bereichs bleibt beim Wechsel zwischen Live- und gespeicherten Logs erhalten. (#570)Beim Öffnen des aktuellen Live-Logs bleibt das automatische Mitlaufen aktiviert. Auch wenn kurze Jobs zwischen zwei Aktualisierungen abgeschlossen werden, wird das letzte verfügbare Job-Log angezeigt. (#570)Mehrere Jobs können gemeinsam über eine übersichtliche Auswahl mit Suche, Standortfiltern und eindeutiger Job-Zuordnung ausgewählt werden. Diese ersetzt das bisherige kompakte Auswahlmenü. (#570)Gruppenkennzeichnungen und Startzeiten im Dashboard bleiben in einer Zeile. Beim Löschen von Gruppen und Verwerfen ungespeicherter Änderungen werden anwendungseigene Dialoge verwendet. Unveränderte Gruppeneinstellungen lassen sich ohne Rückfrage schließen. (#570)Gleich große Aktionsschaltflächen für Gruppen sind einheitlich in der Reihenfolge „Bearbeiten“, „Löschen“ und „Starten“ angeordnet und passend beschriftet. (#570)
October 18Oct 18 Sehr geil ein vorschlag noch, wenn man Job´s in Jobgruppen macht wäre es evtl sinnvoll das man hier noch mal die Scripte eintragen kann ? und das diese dann die Hauptjobs überschreibt ? Edited October 18Oct 18 by Cupra-Bo
October 18Oct 18 Author Borg Backup UI – Version 2026.10.18.1217Die Skriptverwaltung in Jobgruppen wurde erweitert:Pre-/Post-Skripte und die Ausführungsbedingung für Post-Skripte lassen sich direkt in der Jobgruppe anzeigen und ändern.Änderungen werden im ursprünglichen Job gespeichert und gelten sowohl für Einzelstarts als auch für Starts über Jobgruppen.Bereits laufende Jobs verwenden weiterhin die beim Start übernommenen Skripteinstellungen.Gleichzeitige Änderungen an Skriptzuweisungen werden vor dem Speichern erkannt, damit diese nicht unbeabsichtigt überschrieben werden.
October 22Oct 22 Author Borg Backup UI – 2026.10.22.1457VerbesserungenGetrennte Jobkarten mit Schritten, Status, Laufzeiten und aufklappbaren Details.Borg-Fortschrittsanzeige ab 60 Sekunden und Angaben zum letzten erfolgreichen Backup.Verständlichere Speicherstatistiken inklusive freigegebenem Speicher durch borg compact.Live-Log nur auf Klick und weniger unnötige Logmeldungen.Optionales erzwungenes Ausschalten von VMs nach Timeout; standardmäßig deaktiviert.FehlerbehebungenStatusanimationen laufen ohne Neustart weiter; die Schrittanzeige verschwindet beim Abschluss nicht mehr.Benutzerdefinierte Zeitpläne behalten ihre Einstellungen; falsche Überfälligkeitswarnungen wurden behoben.Klarere Fehlermeldungen bei VM-Shutdown-Problemen und verbesserter Wiederanlauf bereits gestoppter VMs.Habt ihr Ideen, wie das Dashboard übersichtlicher und hilfreicher werden könnte? Ich freue mich auf eure Vorschläge! Edited October 22Oct 22 by Thorsten
October 23Oct 23 Author Deutsch – Version 2026.10.23.1054FehlerbehebungenPassende Benachrichtigungsvorschau: Vorlage und Vorschau stimmen jetzt bei allen fünf Backup-Ereignissen überein – einschließlich des Jobnamens im Titel. Die Beschriftungen der mitgelieferten Beispiele folgen der Oberflächensprache. Eigene Texte und Platzhalterwerte bleiben unverändert. Beim Speichern werden die angezeigten Vorlagen für den Versand übernommen.Vollständige Nachrichten in Unraid und Discord: Benachrichtigungen werden vollständig und mit Zeilenumbrüchen dargestellt, auch in der archivierten Unraid-Ansicht. Die Priorität wird separat angezeigt und nicht mehr an den Nachrichtentext angehängt.VerbesserungenEigene Benachrichtigungstexte: Unter Einstellungen > Benachrichtigungen lassen sich Titel und Nachricht für Unraid, E-Mail und Apprise anpassen. Platzhalter wie {job}, {status} und {error} setzen die jeweiligen Backup-Details ein. Leere Felder verwenden den Standardtext.Übersichtlicher Vorlageneditor: Eine zentrale Platzhalterübersicht zeigt Beispielwerte und ermöglicht das Einfügen an der Cursorposition. Gleich große Eingabe- und Vorschaufelder erleichtern den Vergleich. Alle fünf Ereignisse bieten Beispielvorlagen mit Platzhaltern; beim Wechsel zwischen Ereignissen bleiben ungespeicherte Änderungen erhalten.Vielen Dank an JonaxScript für den Beitrag zu den anpassbaren Benachrichtigungstexten!
October 23Oct 23 Author Ich habe das Dashboard von Borg Backup UI überarbeitet und würde gerne eure Meinung dazu hören. 😊Ziel war, die Übersicht ruhiger zu gestalten und wichtige Informationen weiterhin schnell sichtbar zu machen:Zwei Kreise zeigen die letzten Backup-Ergebnisse und die Restore-Nachweise.Unter „Handlungsbedarf“ erscheinen Fehler, Warnungen und überfällige Backups.Die Jobs bleiben nach Standorten gruppiert. Icons, Archivnamen und Repository-Größen sind direkt sichtbar.Weitere Speicherwerte, Borg-Checks und Restore-Daten lassen sich pro Job aufklappen.Was haltet ihr von der neuen Ansicht? Ist sie für euch übersichtlich und informativ genug? Fehlen euch Informationen, oder würdet ihr etwas anders anordnen?Die Bilder zeigen den aktuellen Stand der Testversion – Feedback ist also willkommen.
October 24Oct 24 Author Borg Backup UI – Update 2026.10.24.1534Bug FixesDatenbankexporte werden während der Jobausführung mit Laufzeit und Ergebnis angezeigt. (#591)Prüfung der Dump-Verzeichnisrechte für übliche Unraid-Pools korrigiert. (#591)Verbliebene Browserdialoge durch Anwendungsdialoge ersetzt und Darstellung der Skriptbereiche vereinheitlicht. (#591, #593)ErweiterungenOnline-Datenbanksicherungen für MariaDB/MySQL mit InnoDB und PostgreSQL in Docker – mit Profilen, Datenbankauswahl, geschützten Secrets und komprimierten Dumps. (#591, #593)Überarbeitete Skriptverwaltung mit klarer Trennung zwischen eigenen Skripten, Vorlagen und verwalteten Datenbankhelfern sowie Beschreibungen und Syntaxhervorhebung. (#591)Verbesserte Dashboard-Übersicht für Sicherungsergebnisse, Restore-Nachweise und Jobs mit Handlungsbedarf. (#589)Einzeilige Jobschritte, verständliche Sicherungsnamen und übersichtlichere Auswahl von Verzeichnissen und Datenbankprofilen. (#591)Automatische Bereinigung abgeschlossener interner Vorgangsdaten nach 30 Tagen. Sicherungen und ungeklärte Vorgänge bleiben erhalten. (#593)
October 25Oct 25 Hallo zusammen.Hab die Tage bei meinen Updates gesehen, dass das Python Plugin eingestellt wird. Im Support Text steht "support will end on 30.11.2026". Als Hauptgrund wird die Ankündigung von Unraid 8 genannt. Macht im Prinzip Sinn, wenn Unraid dann eh auf Fedora umstellt. Problem dabei ist, Unraid selber hat noch keinen Releasetermin genannt. Irgendwann nächstes Jahr. Ist die Thematik schon in die Projektplanung eingeflossen? Das Pluginsystem so wie bisher soll es dann wahrscheinlich nicht mehr geben. Wirds dann ein Docker für das Tool kommen? Kannst du da schon irgendwas sagen, wo es hin geht? @Thorsten Danke
October 25Oct 25 Author 1 hour ago, bastl said:Hallo zusammen.Hab die Tage bei meinen Updates gesehen, dass das Python Plugin eingestellt wird. Im Support Text steht "support will end on 30.11.2026". Als Hauptgrund wird die Ankündigung von Unraid 8 genannt. Macht im Prinzip Sinn, wenn Unraid dann eh auf Fedora umstellt. Problem dabei ist, Unraid selber hat noch keinen Releasetermin genannt. Irgendwann nächstes Jahr. Ist die Thematik schon in die Projektplanung eingeflossen? Das Pluginsystem so wie bisher soll es dann wahrscheinlich nicht mehr geben. Wirds dann ein Docker für das Tool kommen? Kannst du da schon irgendwas sagen, wo es hin geht? @ThorstenDankeHallo Bastl,ja, beide Themen – Python und Unraid 8 – habe ich bereits auf dem Schirm und sie sind auch in die Projektplanung von Borg Backup UI eingeflossen.Dazu gibt es bereits zwei GitHub-Issues:Python-Abhängigkeit: Issue #548Unraid 8 und zukünftige Architektur: Issue #549Zum Thema Python:Hier gibt es bereits einen konkreten Plan. Borg Backup UI soll spätestens mit dem Wegfall der Unterstützung für das bisherige Python-Plugin am 30.11.2026 unabhängig davon funktionieren.Dafür wird Borg Backup UI bei Bedarf eine eigene, isolierte Python-Laufzeitumgebung mitbringen. Diese dient ausschließlich der Ausführung von Borg Backup UI und wird nicht systemweit installiert. Ist bereits eine kompatible Python-Version vorhanden, kann diese weiterhin verwendet werden.Damit sollte die weitere Nutzung unter Unraid 7.x unabhängig vom bisherigen Python-Plugin möglich sein.Bei Unraid 8 sieht es diesbezüglich ohnehin etwas anders aus, da Python laut den bisherigen Ankündigungen bereits Bestandteil der neuen Fedora-basierten Plattform sein soll.Zum Thema Unraid 8:Hier sind leider noch einige Fragen offen. Nach den aktuellen Informationen wird die öffentliche Beta für Anfang 2027 angestrebt. Ein konkreter Termin für die finale Version steht noch nicht fest.Unraid arbeitet an einem neuen Plugin-System mit einem eigenen SDK und einer Rechteverwaltung. Bestehende Plugins müssen dafür angepasst werden. Gleichzeitig wurde angekündigt, dass man die Community-Entwickler bei dieser Umstellung unterstützen möchte.Welche Möglichkeiten sich daraus konkret für Borg Backup UI ergeben, muss sich allerdings erst noch zeigen.Parallel dazu beschäftige ich mich auch mit der Frage, ob langfristig eine eigenständige Container-Version sinnvoll wäre.Hier gibt es momentan zwei Überlegungen:1. Ein Container mit erweiterten Host-Rechten (privileged)Damit ließen sich viele der bestehenden Funktionen vergleichsweise einfach umsetzen, da Borg Backup UI für verschiedene Aufgaben tiefen Zugriff auf das Host-System benötigt, beispielsweise für Docker, virtuelle Maschinen, Datenträger und Backup-/Restore-Prozesse.Allerdings hätte ein solcher Container sehr weitreichende Berechtigungen, was aus Sicherheitsgründen natürlich nicht unbedingt die schönste Lösung ist.2. Ein normaler Container mit einem Host-AgentenHier würde die eigentliche Anwendung in einem möglichst eingeschränkten Container laufen. Ein separater Agent auf dem Host würde die notwendigen systemnahen Aufgaben übernehmen.Das wäre hinsichtlich der Trennung von Anwendung und Host eine interessante Alternative, bringt aber ebenfalls Herausforderungen mit sich. Insbesondere dann, wenn Borg Backup UI irgendwann nicht mehr ausschließlich für Unraid, sondern möglicherweise auch für andere Plattformen wie TrueNAS, Synology oder klassische Linux-Systeme angeboten werden soll.Welche Variante am Ende die sinnvollste ist, habe ich noch nicht entschieden. Auch eine Anpassung des bestehenden Plugins an das neue Unraid-8-System bleibt selbstverständlich eine Option.Was ich aber schon sagen kann:Borg Backup UI wird auf jeden Fall weiterentwickelt. Mein Ziel ist es, den Übergang für euch als Anwender so einfach wie möglich zu gestalten – idealerweise ohne eine komplette Neueinrichtung und natürlich unter Beibehaltung eurer bestehenden Konfigurationen, Backup-Jobs und Repositories.Auch Unraid 7.x werde ich weiterhin unterstützen und pflegen, unabhängig davon, wann Unraid 8 erscheint.Eine weitere Sache steht ebenfalls auf der Roadmap: Sobald BorgBackup 2.x als stabile Version verfügbar ist, soll auch diese von Borg Backup UI unterstützt werden.Es stehen also noch einige interessante Entwicklungen bevor. 🙂Und noch etwas ist mir wichtig:Borg Backup UI lebt natürlich auch von euch und eurem Feedback. Deshalb freue ich mich jederzeit über Wünsche, Ideen, Verbesserungsvorschläge und natürlich auch konstruktive Kritik.Nur durch eure Rückmeldungen kann ich erkennen, welche Funktionen euch vielleicht noch fehlen, wo es im Alltag Schwierigkeiten gibt oder was sich einfacher und besser gestalten lässt.Bringt euch also gerne ein, egal ob hier im Forum oder direkt über GitHub. Nicht jeder Wunsch lässt sich sofort umsetzen, aber jede Anregung hilft mir dabei, Borg Backup UI weiterzuentwickeln und noch besser an euren tatsächlichen Bedürfnissen auszurichten.Schließlich entwickle ich Borg Backup UI nicht nur für mich, sondern vor allem auch für euch. 🙂Viele GrüßeThorsten Edited October 25Oct 25 by Thorsten
October 26Oct 26 21 hours ago, Thorsten said:2. Ein normaler Container mit einem Host-AgentenHier würde die eigentliche Anwendung in einem möglichst eingeschränkten Container laufen. Ein separater Agent auf dem Host würde die notwendigen systemnahen Aufgaben übernehmen.Servus.Ich denke ein normaler Container mit einem zusätzlichen Agenten für den Host macht am meisten Sinn. Wer quasi nur Verzeichnisse sichern möchte ist mit dem "normalen" Container gut bedient, egal auf welchem System der dann läuft. Wenn man dann noch Zugriff zum Host benötigt ist die Idee mit nem Host-Agent eigentlich ganz clever. Je nach Host System einfach den passenden Agent installiert. Problem ist nur, dass man dann auch mehrere Agents pflegen muß. Einer für Unraid, einer für TrueNAS, Proxmox etc.Bisher lief es bei mir eigentlich ohne Probleme, bis vor 2 Wochen einer der Restore Tests nicht abgeschlossen wurde. Ich hatte mir das angeschaut und gemerkt, dass wenn der Test läuft, mein System dann den RAM komplett zu haut, was dazu geführt hat, dass eine von 2 VMs die immer läuft gekillt wurde und der Test abbrach. Ich hab der VM dann vorsorglich 2GB RAM entzogen, von 8 auf 6 und der Test lief dann manuell gestartet durch. Letzte Woche lief der Test ebenso ohne Probleme automatisch, nur gestern leider wieder nicht. Gleiche Symptome, Borg vermeldet, dass der Test abgebrochen wurde.Schau ich mir dann den Prüfbericht an, scheint es bei Metadaten-Check nen Timeout gegeben zu haben. Repo erreichbar und Archiv lesbar beides grün, danach Feierabend. Ich hab leider keinen Screenshot gemacht und finde nachdem ich den Lauf nochmal von Hand gestartet hab, keine Infos/Logs zu dem abgebrochenen Durchlauf mehr. Entweder bin ich blind oder es gibt keine Option dazu. Ich hab hier aber noch nen Auszug aus dem Unraid Log (siehe Anhang) selbst falls das weiter helfen könnte. Eine Anmerkung hierzu, der eigentliche Durchlauf der geplant war, bzw. keiner der geplanten Durchläufe hat etwas in den Unraid Logs hinterlassen, weder den Start, noch Warnungen oder Meldungen auch das killen der VM ist nicht aufgeführt.19:30 läuft nen Trim Durchlauf vom Cache etwa 5 Min. Danach passiert nix weiter auf dem Server. 20Uhr sind die Tests geplant und auch diese sieht man in den Unraid Logs nicht. Ursprünglich hab ich alle 5 auf die gleiche Zeit gelegt, vor 3 Wochen nach dem ersten Absturz der VM dann den betreffenden Test vom "appdata" Repo auf um 22Uhr nach hinten geschoben. Die anderen 4 Tests liefen immer ohne Probleme, nur der appdata Test verursacht Probleme. Kurz vor halb 1 hab ich den Test dann von Hand angestoßen mit laufender VM und kurz darauf schießt es mir wieder die VM ab. Der Testlauf läuft aber erfolgreich durch.Hier noch ein paar Anmerkungen zum Setup:Im Idle läuft der Server mit 70-80% RAM usage, wobei an dem Punkt 5-6GB von 32 gesamt noch frei sind. Während des Tests und auch während der anderen Repo Tests läuft der RAM hoch bis auf 92-93% zumindest sieht man das in der Unraid UI so. Nur bei dem "appdata" Repo gibt es aber das Problem. Während der Laufzeit des Tests sowohl geplant als auch danach manuel gestartet läuft auf dem Server nichts weiter aktiv. Docker wie Nextcloud und Jellyfin sind zwar aktiv, haben zu der Zeit aber keine Nutzer und auch keine Management Jobs laufen. Die betroffene VM ist auch im Idle.Info zum Repo:gesichert wird ein Verzeichnis in dem sich mehrere rsync Sicherungen vom Appdata Verzeichnis befinden. Etwa 180K Dateien befinden sich in einer Rsync Sicherung ca. 32GB. Suma sumarum sollen etwa 1,8mio Dateien gesichert werden. Ich weis, nicht gerade wenig und dauert auch über ne Stunde, aber im Prinzip egal. Sicherung läuft ja auch problemlos. Die Backups laufen auch eigentlich mit Standard Settings bis auf die Komprimierung. Diese steht bei allen auf zstd 6 statt 4. Die Restore Test settings stehen ebenfalls auf den Default Werten. L2 bei allen Tests.Folgendes hat mir der Manuelle Lauf gestern noch im Verlauf angezeigt:[2026-10-26 00:24:34] ============================================================ [2026-10-26 00:24:34] Borg Restore Test v1.0.0 [2026-10-26 00:24:34] Level: 2 | Location: all | Force: True [2026-10-26 00:24:34] Log: /mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-26_00-24-34-1027308.log [2026-10-26 00:24:34] ============================================================ [2026-10-26 00:24:34] Repositories: 1 [2026-10-26 00:24:34] Restore-test policy: job=b6c9c136-255d-4887-a4b0-f3757b6c39ba; level=L2; schedule=0 22 * * 0; source=manual [2026-10-26 00:24:34] ──────────────────────────────────────────────────────────── [2026-10-26 00:24:34] TEST: appdata (local) [2026-10-26 00:24:34] Repository: /mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/borg-backup-ui/borg-backup-appdata [2026-10-26 00:24:34] Level 1: Repository integrity [2026-10-26 00:24:35] OK Level 1 - latest archive: appdata-backup-2026-10-25_09-15-04 [2026-10-26 00:24:45] Size: 89.3 GB, files: 630030 [2026-10-26 00:24:45] Level 2: Extract Dry-Run [2026-10-26 00:30:04] Testing the complete archive (1921601 files) [2026-10-26 01:21:10] → Ergebnis: /mnt/user/borg-backup-ui/restore-status/b6c9c136-255d-4887-a4b0-f3757b6c39ba.test [2026-10-26 01:21:11] Unraid dashboard widget cache updated (restore test result written) [2026-10-26 01:21:11] OK Restore test succeeded (3396s) [2026-10-26 01:21:11] ============================================================ [2026-10-26 01:21:11] Summary: 1 OK | 0 failed | 0 unavailable | 0 skippedWie man sieht 1,9mio Files deckt sich also mit meiner groben Schätzung. Metadatencheck is in 10s durch und Restore-Probe dauerte etwa 56min. Docker und VMs werden durch Borg Backup UI nicht angetastet, nur das reine Dateiverzeichnisse wird gesichert auf ein gemounteten NFS Share zu einem Synology NAS.Frage ist nun, wie kann ich verhindern, dass mir das Plugin irgendwelche VMs und Dienste abschießt? Kann ich irgendwo die Arbeitsspeichernutzung begrenzen? Sollte falls nicht vorhanden unbedingt auf die ToDo List, dass das Plugin sich nicht einfach gnadenlos nimmt bis nix mehr da is. 🤣Danke schonmal unraid-log-snippet.log
October 26Oct 26 Author 1 hour ago, bastl said:Servus.Ich denke ein normaler Container mit einem zusätzlichen Agenten für den Host macht am meisten Sinn. Wer quasi nur Verzeichnisse sichern möchte ist mit dem "normalen" Container gut bedient, egal auf welchem System der dann läuft. Wenn man dann noch Zugriff zum Host benötigt ist die Idee mit nem Host-Agent eigentlich ganz clever. Je nach Host System einfach den passenden Agent installiert. Problem ist nur, dass man dann auch mehrere Agents pflegen muß. Einer für Unraid, einer für TrueNAS, Proxmox etc.Bisher lief es bei mir eigentlich ohne Probleme, bis vor 2 Wochen einer der Restore Tests nicht abgeschlossen wurde. Ich hatte mir das angeschaut und gemerkt, dass wenn der Test läuft, mein System dann den RAM komplett zu haut, was dazu geführt hat, dass eine von 2 VMs die immer läuft gekillt wurde und der Test abbrach. Ich hab der VM dann vorsorglich 2GB RAM entzogen, von 8 auf 6 und der Test lief dann manuell gestartet durch. Letzte Woche lief der Test ebenso ohne Probleme automatisch, nur gestern leider wieder nicht. Gleiche Symptome, Borg vermeldet, dass der Test abgebrochen wurde.Schau ich mir dann den Prüfbericht an, scheint es bei Metadaten-Check nen Timeout gegeben zu haben. Repo erreichbar und Archiv lesbar beides grün, danach Feierabend. Ich hab leider keinen Screenshot gemacht und finde nachdem ich den Lauf nochmal von Hand gestartet hab, keine Infos/Logs zu dem abgebrochenen Durchlauf mehr. Entweder bin ich blind oder es gibt keine Option dazu. Ich hab hier aber noch nen Auszug aus dem Unraid Log (siehe Anhang) selbst falls das weiter helfen könnte. Eine Anmerkung hierzu, der eigentliche Durchlauf der geplant war, bzw. keiner der geplanten Durchläufe hat etwas in den Unraid Logs hinterlassen, weder den Start, noch Warnungen oder Meldungen auch das killen der VM ist nicht aufgeführt.19:30 läuft nen Trim Durchlauf vom Cache etwa 5 Min. Danach passiert nix weiter auf dem Server. 20Uhr sind die Tests geplant und auch diese sieht man in den Unraid Logs nicht. Ursprünglich hab ich alle 5 auf die gleiche Zeit gelegt, vor 3 Wochen nach dem ersten Absturz der VM dann den betreffenden Test vom "appdata" Repo auf um 22Uhr nach hinten geschoben. Die anderen 4 Tests liefen immer ohne Probleme, nur der appdata Test verursacht Probleme. Kurz vor halb 1 hab ich den Test dann von Hand angestoßen mit laufender VM und kurz darauf schießt es mir wieder die VM ab. Der Testlauf läuft aber erfolgreich durch.Hier noch ein paar Anmerkungen zum Setup:Im Idle läuft der Server mit 70-80% RAM usage, wobei an dem Punkt 5-6GB von 32 gesamt noch frei sind. Während des Tests und auch während der anderen Repo Tests läuft der RAM hoch bis auf 92-93% zumindest sieht man das in der Unraid UI so.Nur bei dem "appdata" Repo gibt es aber das Problem. Während der Laufzeit des Tests sowohl geplant als auch danach manuel gestartet läuft auf dem Server nichts weiter aktiv. Docker wie Nextcloud und Jellyfin sind zwar aktiv, haben zu der Zeit aber keine Nutzer und auch keine Management Jobs laufen. Die betroffene VM ist auch im Idle.Info zum Repo:gesichert wird ein Verzeichnis in dem sich mehrere rsync Sicherungen vom Appdata Verzeichnis befinden. Etwa 180K Dateien befinden sich in einer Rsync Sicherung ca. 32GB. Suma sumarum sollen etwa 1,8mio Dateien gesichert werden. Ich weis, nicht gerade wenig und dauert auch über ne Stunde, aber im Prinzip egal. Sicherung läuft ja auch problemlos. Die Backups laufen auch eigentlich mit Standard Settings bis auf die Komprimierung. Diese steht bei allen auf zstd 6 statt 4. Die Restore Test settings stehen ebenfalls auf den Default Werten. L2 bei allen Tests.Folgendes hat mir der Manuelle Lauf gestern noch im Verlauf angezeigt:[2026-10-26 00:24:34] ============================================================ [2026-10-26 00:24:34] Borg Restore Test v1.0.0 [2026-10-26 00:24:34] Level: 2 | Location: all | Force: True [2026-10-26 00:24:34] Log: /mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-26_00-24-34-1027308.log [2026-10-26 00:24:34] ============================================================ [2026-10-26 00:24:34] Repositories: 1 [2026-10-26 00:24:34] Restore-test policy: job=b6c9c136-255d-4887-a4b0-f3757b6c39ba; level=L2; schedule=0 22 * * 0; source=manual [2026-10-26 00:24:34] ──────────────────────────────────────────────────────────── [2026-10-26 00:24:34] TEST: appdata (local) [2026-10-26 00:24:34] Repository: /mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/borg-backup-ui/borg-backup-appdata [2026-10-26 00:24:34] Level 1: Repository integrity [2026-10-26 00:24:35] OK Level 1 - latest archive: appdata-backup-2026-10-25_09-15-04 [2026-10-26 00:24:45] Size: 89.3 GB, files: 630030 [2026-10-26 00:24:45] Level 2: Extract Dry-Run [2026-10-26 00:30:04] Testing the complete archive (1921601 files) [2026-10-26 01:21:10] → Ergebnis: /mnt/user/borg-backup-ui/restore-status/b6c9c136-255d-4887-a4b0-f3757b6c39ba.test [2026-10-26 01:21:11] Unraid dashboard widget cache updated (restore test result written) [2026-10-26 01:21:11] OK Restore test succeeded (3396s) [2026-10-26 01:21:11] ============================================================ [2026-10-26 01:21:11] Summary: 1 OK | 0 failed | 0 unavailable | 0 skippedWie man sieht 1,9mio Files deckt sich also mit meiner groben Schätzung. Metadatencheck is in 10s durch und Restore-Probe dauerte etwa 56min. Docker und VMs werden durch Borg Backup UI nicht angetastet, nur das reine Dateiverzeichnisse wird gesichert auf ein gemounteten NFS Share zu einem Synology NAS.Frage ist nun, wie kann ich verhindern, dass mir das Plugin irgendwelche VMs und Dienste abschießt? Kann ich irgendwo die Arbeitsspeichernutzung begrenzen? Sollte falls nicht vorhanden unbedingt auf die ToDo List, dass das Plugin sich nicht einfach gnadenlos nimmt bis nix mehr da is. 🤣Danke schonmalunraid-log-snippet.logJa. Der Log bestätigt einen echten RAM-Engpass, und der Restore-Test-Code enthält eine dazu passende Schwachstelle. Eine einstellbare RAM-Begrenzung gibt es derzeit nicht.Am 26.10. um 00:29:46 hat der Linux-OOM-Killer die VM MintL beendet. Der Python-Prozess des Restore-Tests belegte dabei etwa 3,56 GiB RAM. Ein weiterer, anhand des Auszugs nicht zuordenbarer Python-Prozess belegte rund 5,28 GiB. Swap war nicht vorhanden.Besonders aufschlussreich ist der Zeitpunkt: Erst um 00:30:04, also nach dem VM-Abschuss, beginnt laut Protokoll der vollständige Extract-Dry-Run. Der Speicherengpass entstand somit bereits während der Vorbereitung der Dateiliste.Im [Restore-Test-Code (line 811)](/home/tsteinbe/git/borg-backup-ui/runtime/scripts/borg_restore_test.py:811) passiert Folgendes:Die komplette Ausgabe von borg list --json-lines wird im RAM gesammelt.splitlines() erzeugt zusätzliche Zeichenketten für sämtliche Einträge.Zusätzlich werden alle regulären Dateipfade in einer Liste gespeichert.Erst danach greifen Stichprobenauswahl und Dateilimits.Bei 1,9 Millionen Dateien ist das ein plausibler erheblicher Speicherverbrauch des Plugins selbst. Kleinere Stichproben oder ein niedrigerer Schwellwert für den vollständigen Dry-Run beheben diesen Vorbereitungsschritt nicht.Zu den verschwundenen Berichten: Du hast keine Verlaufsoption übersehen. Der strukturierte Prüfbericht wird pro Job überschrieben. Die separaten Textprotokolle sollten dagegen noch unter /mnt/user/borg-backup-ui/logs/ als Borg-Restore-Test--<Zeitstempel>-<PID>.log liegen. Allgemeine Ablaufmeldungen gehen in /var/log/borg_backup_ui.log, nicht in den Unraid-Syslog. Den vermuteten Timeout des vorherigen geplanten Laufs kann ich ohne dessen Protokoll nicht bestätigen.Bis zur Behebung würde ich den automatischen L2-Test für appdata vorübergehend deaktivieren. L1 vermeidet die hier problematische vollständige Dateiauflistung, bietet allerdings keine Prüfung der Nutzdaten und keine garantierte RAM-Obergrenze. Nur den Timeout zu verkürzen ist kein verlässlicher Speicherschutz.Ich habe die Befunde als Issue #599 erfasst. Die notwendigen Maßnahmen sind:Dateilisten streamen und nur eine begrenzte Stichprobe speichern.Ein durchgesetztes Speicherbudget für Testprozess und Borg-Unterprozesse vorsehen.Abbrüche eindeutig melden und Prüfberichte samt Logverweisen pro Lauf erhalten.VG Thorsten Edited October 26Oct 26 by Thorsten
October 26Oct 26 28 minutes ago, Thorsten said:Die separaten Textprotokolle sollten dagegen noch unter /mnt/user/borg-backup-ui/logs/ als Borg-Restore-Test--<Zeitstempel>-<PID>.log liegen.Hier noch das Log von dem automatischen Task der fehlerhaft war. Wird aber denke ich nicht sehr hilfreich sein. Mehr als dass man sieht, dass er nach ner Minute etwa abbricht sieht man leider nicht. [2026-10-25 22:00:01] ============================================================ [2026-10-25 22:00:01] Borg Restore Test v1.0.0 [2026-10-25 22:00:01] Level: 2 | Location: all | Force: False [2026-10-25 22:00:01] Log: /mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-25_22-00-01-476656.log [2026-10-25 22:00:01] ============================================================ [2026-10-25 22:00:02] Repositories: 1 [2026-10-25 22:00:02] Restore-test policy: job=b6c9c136-255d-4887-a4b0-f3757b6c39ba; level=L2; schedule=0 22 * * 0; source=schedule [2026-10-25 22:00:02] ──────────────────────────────────────────────────────────── [2026-10-25 22:00:02] TEST: appdata (local) [2026-10-25 22:00:02] Repository: /mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/borg-backup-ui/borg-backup-appdata [2026-10-25 22:00:02] Level 1: Repository integrity [2026-10-25 22:00:04] OK Level 1 - latest archive: appdata-backup-2026-10-25_09-15-04 [2026-10-25 22:01:04] Level 2: Extract Dry-Run [2026-10-25 22:01:06] → Ergebnis: /mnt/user/borg-backup-ui/restore-status/b6c9c136-255d-4887-a4b0-f3757b6c39ba.test [2026-10-25 22:01:07] Unraid dashboard widget cache updated (restore test result written) [2026-10-25 22:01:07] ============================================================ [2026-10-25 22:01:07] Summary: 0 OK | 1 failed | 0 unavailable | 0 skippedUnd dazu noch der Ausschnitt aus den allgemeinen Logs des Plugins zu dem Zeitpunkt. Vielleicht siehst du dort ja noch etwas hilfreiches:[2026-10-25 22:00:01] RESTORE_TEST requested request_id=32cd3132b44b source=schedule actor=scheduler run_id=20261025T210001Z-f0d6296ee0cd level=2 location=all selected_jobs=["b6c9c136-255d-4887-a4b0-f3757b6c39ba"] auto_selected=false [2026-10-25 22:00:01] API ok request_id=32cd3132b44b status=200 method=POST path=/api/restore-tests/run-job duration_ms=48 bytes=246 context={"job_key": "b6c9c136-255d-4887-a4b0-f3757b6c39ba", "phase": "restore-test-run", "source": "schedule", "run_id": "20261025T210001Z-f0d6296ee0cd", "selected_jobs": ["b6c9c136-255d-4887-a4b0-f3757b6c39ba"]} [2026-10-25 22:00:01] RESTORE_TEST process_started request_id=32cd3132b44b source=schedule actor=scheduler run_id=20261025T210001Z-f0d6296ee0cd pid=476656 level=2 location=all log_file=/mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-25_22-00-01-476656.log selected_jobs=["b6c9c136-255d-4887-a4b0-f3757b6c39ba"] [2026-10-25 22:01:07] RESTORE_TEST notification job_key=b6c9c136-255d-4887-a4b0-f3757b6c39ba event=restore_test_failed source=restore_test status=Failed duration_seconds=64 exit_code=0 unraid=true email=false apprise=false apprise_mode=queued [2026-10-25 22:01:07] RESTORE_TEST finished request_id=32cd3132b44b source=schedule actor=scheduler run_id=20261025T210001Z-f0d6296ee0cd status=failed exit_code=1 duration_seconds=65 log_file=/mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-25_22-00-01-476656.log ok_count=0 failed_count=1 unavailable_count=0 skipped_count=0 [2026-10-25 22:14:12] RESTORE_TEST notification job_key=b6c9c136-255d-4887-a4b0-f3757b6c39ba event=restore_test_overdue source=scheduled_reminder status=overdue duration_seconds=0 exit_code=0 unraid=true email=false apprise=false apprise_mode=queued [2026-10-25 22:14:12] Notification reminders checked: checked=6 sent=1 skipped=0 [2026-10-25 23:14:12] Notification reminders checked: checked=6 sent=0 skipped=1 Beide Log-Ausschnitte sind nur für den ursprünglichen automatischen Test-Task der fehlerhaft war. In dem später manuel gestartete Lauf seh ich in den Logs auch nichts, außer "API ok requests" zum Status. Falls du noch was benötigst an Info, sag Bescheid. Ich stell erstmal auf L1 um für das Repo und behalte es im Blick.
October 26Oct 26 Author 2 hours ago, bastl said:Hier noch das Log von dem automatischen Task der fehlerhaft war. Wird aber denke ich nicht sehr hilfreich sein. Mehr als dass man sieht, dass er nach ner Minute etwa abbricht sieht man leider nicht.[2026-10-25 22:00:01] ============================================================ [2026-10-25 22:00:01] Borg Restore Test v1.0.0 [2026-10-25 22:00:01] Level: 2 | Location: all | Force: False [2026-10-25 22:00:01] Log: /mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-25_22-00-01-476656.log [2026-10-25 22:00:01] ============================================================ [2026-10-25 22:00:02] Repositories: 1 [2026-10-25 22:00:02] Restore-test policy: job=b6c9c136-255d-4887-a4b0-f3757b6c39ba; level=L2; schedule=0 22 * * 0; source=schedule [2026-10-25 22:00:02] ──────────────────────────────────────────────────────────── [2026-10-25 22:00:02] TEST: appdata (local) [2026-10-25 22:00:02] Repository: /mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/borg-backup-ui/borg-backup-appdata [2026-10-25 22:00:02] Level 1: Repository integrity [2026-10-25 22:00:04] OK Level 1 - latest archive: appdata-backup-2026-10-25_09-15-04 [2026-10-25 22:01:04] Level 2: Extract Dry-Run [2026-10-25 22:01:06] → Ergebnis: /mnt/user/borg-backup-ui/restore-status/b6c9c136-255d-4887-a4b0-f3757b6c39ba.test [2026-10-25 22:01:07] Unraid dashboard widget cache updated (restore test result written) [2026-10-25 22:01:07] ============================================================ [2026-10-25 22:01:07] Summary: 0 OK | 1 failed | 0 unavailable | 0 skippedUnd dazu noch der Ausschnitt aus den allgemeinen Logs des Plugins zu dem Zeitpunkt. Vielleicht siehst du dort ja noch etwas hilfreiches:[2026-10-25 22:00:01] RESTORE_TEST requested request_id=32cd3132b44b source=schedule actor=scheduler run_id=20261025T210001Z-f0d6296ee0cd level=2 location=all selected_jobs=["b6c9c136-255d-4887-a4b0-f3757b6c39ba"] auto_selected=false [2026-10-25 22:00:01] API ok request_id=32cd3132b44b status=200 method=POST path=/api/restore-tests/run-job duration_ms=48 bytes=246 context={"job_key": "b6c9c136-255d-4887-a4b0-f3757b6c39ba", "phase": "restore-test-run", "source": "schedule", "run_id": "20261025T210001Z-f0d6296ee0cd", "selected_jobs": ["b6c9c136-255d-4887-a4b0-f3757b6c39ba"]} [2026-10-25 22:00:01] RESTORE_TEST process_started request_id=32cd3132b44b source=schedule actor=scheduler run_id=20261025T210001Z-f0d6296ee0cd pid=476656 level=2 location=all log_file=/mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-25_22-00-01-476656.log selected_jobs=["b6c9c136-255d-4887-a4b0-f3757b6c39ba"] [2026-10-25 22:01:07] RESTORE_TEST notification job_key=b6c9c136-255d-4887-a4b0-f3757b6c39ba event=restore_test_failed source=restore_test status=Failed duration_seconds=64 exit_code=0 unraid=true email=false apprise=false apprise_mode=queued [2026-10-25 22:01:07] RESTORE_TEST finished request_id=32cd3132b44b source=schedule actor=scheduler run_id=20261025T210001Z-f0d6296ee0cd status=failed exit_code=1 duration_seconds=65 log_file=/mnt/user/borg-backup-ui/logs/Borg-Restore-Test--2026-10-25_22-00-01-476656.log ok_count=0 failed_count=1 unavailable_count=0 skipped_count=0 [2026-10-25 22:14:12] RESTORE_TEST notification job_key=b6c9c136-255d-4887-a4b0-f3757b6c39ba event=restore_test_overdue source=scheduled_reminder status=overdue duration_seconds=0 exit_code=0 unraid=true email=false apprise=false apprise_mode=queued [2026-10-25 22:14:12] Notification reminders checked: checked=6 sent=1 skipped=0 [2026-10-25 23:14:12] Notification reminders checked: checked=6 sent=0 skipped=1 Beide Log-Ausschnitte sind nur für den ursprünglichen automatischen Test-Task der fehlerhaft war. In dem später manuel gestartete Lauf seh ich in den Logs auch nichts, außer "API ok requests" zum Status. Falls du noch was benötigst an Info, sag Bescheid. Ich stell erstmal auf L1 um für das Repo und behalte es im Blick.Servus! Mit Version 2026.10.26.1618 haben wir die Restore-Tests überarbeitet:Große Dateilisten werden jetzt zeilenweise verarbeitet, statt komplett im RAM gehalten. Der Prüfumfang bleibt gleich.Es gibt ein RAM-Limit für den Test einschließlich Borg und eine überwachte Speicherreserve für den Host.Frühere Prüfberichte bleiben nach einem erneuten Test erhalten.Ein Unraid-spezifisches Problem beim abschließenden Auslesen der Speicherzähler wurde behoben.Meine Appdata-Sicherung mit rund 500.000 Dateien aus 31 Containern läuft erfolgreich durch. Dein Archiv mit etwa 1,9 Millionen Dateien ist daher der nächste wichtige Praxistest.Bitte einmal so testen:Plugin aktualisieren und Version 2026.10.26.1618 kontrollieren.Unter Einstellungen → Restore → Restore-Tests zunächst 2048 MiB RAM-Limit und 1024 MiB Hostreserve verwenden. Dafür müssen vor dem Start mindestens 3 GiB RAM verfügbar sein.Zuerst einen kleinen L2-Test durchführen, anschließend den problematischen Appdata-Test mit den bisherigen L2-Einstellungen. Zunächst keine weiteren Restore-Tests parallel starten.RAM-Auslastung und Erreichbarkeit der VMs währenddessen beobachten.Bei Erfolg sollten am Ende diese Zeilen erscheinen:Final memory counters: oom=0, oom_kill=0 Summary: 1 OK | 0 failed | 0 unavailable | 0 skippedFalls RT_MEMORY_LIMIT erscheint, bitte zunächst das Limit unverändert lassen und das Log schicken. Das bedeutet, dass das Speicherbudget erreicht wurde, und weist allein nicht auf ein beschädigtes Backup hin.Bitte anschließend das vollständige Laufprotokoll, die höchste beobachtete RAM-Auslastung und eine kurze Rückmeldung zu den VMs und Diensten senden.VG Thorsten
October 26Oct 26 Community Expert Was mir ausfällt.Identische Backups (ähnliche, vergleichbare Einstellungen und identische Laufzeit (vergleichbar, kaum veränderte Daten im Backup): jedes Programm backupt auf einer eigenen 1TB usb FestplatteBorg Backup UI: 1TB voll nach einer Woche (bis Anschlag) - wurde nie kleinerBorg-UI: 496GB nach einer Woche - bleibt ziemlich stabilFrage mich warum ;-)BG Dirk Edited October 26Oct 26 by dibux
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.