[Plugin] CA Appdata Backup / Restore v2


Squid

Recommended Posts

5 hours ago, Squid said:

The logs would have stated that an error of some sort happened during the backups.  In an error situation, the old backup sets don't get deleted.  This is why your earliest set 4/25 still exists.  Pretty sure that a notification goes out in the error situation

 

I believe the relevant portion of the log is in the spoiler. I don't see any errors indicated here, and the pushover notification definitely says Backup Complete. No trace of what happend with influx either.

 

Running Unraid 6.9.2, plugin dated 2021.03.13 which I see isn't the newest. 

 

EDIT: I didn't find the correct line earlier. It does in fact indicate that the source couldn't be found, which is because I've moved my appdata from /mnt/cache/appdata to a new nvme disk at /mnt/cache_nvme/appdata. Oops.. Still no clue why Influxdb messed up so bad

 

EDIT2: It's obviously much better to backup /mnt/user/appdata than pointing it directly to the drives. I don't know what I was thinking when I set it up..

 

 

Spoiler
Nov 25 04:00:01 Tower CA Backup/Restore: #######################################
Nov 25 04:00:01 Tower CA Backup/Restore: Community Applications appData Backup
Nov 25 04:00:01 Tower CA Backup/Restore: Applications will be unavailable during
Nov 25 04:00:01 Tower CA Backup/Restore: this process.  They will automatically
Nov 25 04:00:01 Tower CA Backup/Restore: be restarted upon completion.
Nov 25 04:00:01 Tower CA Backup/Restore: #######################################
Nov 25 04:00:01 Tower CA Backup/Restore: Stopping binhex-krusader
Nov 25 04:00:02 Tower kernel: docker0: port 19(vethc3b91c6) entered disabled state
Nov 25 04:00:02 Tower kernel: vethb09ae0e: renamed from eth0
Nov 25 04:00:02 Tower avahi-daemon[11847]: Interface vethc3b91c6.IPv6 no longer relevant for mDNS.
Nov 25 04:00:02 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethc3b91c6.IPv6 with address fe80::c8bc:f6ff:fe11:2dd0.
Nov 25 04:00:02 Tower kernel: docker0: port 19(vethc3b91c6) entered disabled state
Nov 25 04:00:02 Tower kernel: device vethc3b91c6 left promiscuous mode
Nov 25 04:00:02 Tower kernel: docker0: port 19(vethc3b91c6) entered disabled state
Nov 25 04:00:02 Tower avahi-daemon[11847]: Withdrawing address record for fe80::c8bc:f6ff:fe11:2dd0 on vethc3b91c6.
Nov 25 04:00:02 Tower CA Backup/Restore: docker stop -t 60 binhex-krusader
Nov 25 04:00:02 Tower CA Backup/Restore: Stopping binhex-plexpass
Nov 25 04:00:04 Tower CA Backup/Restore: docker stop -t 60 binhex-plexpass
Nov 25 04:00:04 Tower CA Backup/Restore: Stopping Dozzle
Nov 25 04:00:04 Tower kernel: docker0: port 18(vethc03ad45) entered disabled state
Nov 25 04:00:04 Tower kernel: veth1beb0cc: renamed from eth0
Nov 25 04:00:04 Tower avahi-daemon[11847]: Interface vethc03ad45.IPv6 no longer relevant for mDNS.
Nov 25 04:00:04 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethc03ad45.IPv6 with address fe80::78ab:aaff:fe16:3d85.
Nov 25 04:00:04 Tower kernel: docker0: port 18(vethc03ad45) entered disabled state
Nov 25 04:00:04 Tower kernel: device vethc03ad45 left promiscuous mode
Nov 25 04:00:04 Tower kernel: docker0: port 18(vethc03ad45) entered disabled state
Nov 25 04:00:04 Tower avahi-daemon[11847]: Withdrawing address record for fe80::78ab:aaff:fe16:3d85 on vethc03ad45.
Nov 25 04:00:04 Tower CA Backup/Restore: docker stop -t 60 Dozzle
Nov 25 04:00:04 Tower CA Backup/Restore: Stopping Grafana
Nov 25 04:00:04 Tower kernel: docker0: port 1(veth6d0cfee) entered disabled state
Nov 25 04:00:04 Tower kernel: veth607e372: renamed from eth0
Nov 25 04:00:04 Tower avahi-daemon[11847]: Interface veth6d0cfee.IPv6 no longer relevant for mDNS.
Nov 25 04:00:04 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth6d0cfee.IPv6 with address fe80::942e:c1ff:feb9:64eb.
Nov 25 04:00:04 Tower kernel: docker0: port 1(veth6d0cfee) entered disabled state
Nov 25 04:00:04 Tower kernel: device veth6d0cfee left promiscuous mode
Nov 25 04:00:04 Tower kernel: docker0: port 1(veth6d0cfee) entered disabled state
Nov 25 04:00:04 Tower avahi-daemon[11847]: Withdrawing address record for fe80::942e:c1ff:feb9:64eb on veth6d0cfee.
Nov 25 04:00:04 Tower CA Backup/Restore: docker stop -t 60 Grafana
Nov 25 04:00:04 Tower CA Backup/Restore: Stopping habridge
Nov 25 04:00:13 Tower kernel: veth9c4dacc: renamed from eth0
Nov 25 04:00:13 Tower CA Backup/Restore: docker stop -t 60 habridge
Nov 25 04:00:13 Tower CA Backup/Restore: Stopping Influxdb2
Nov 25 04:00:13 Tower kernel: docker0: port 2(veth76f0742) entered disabled state
Nov 25 04:00:13 Tower kernel: veth2458fd8: renamed from eth0
Nov 25 04:00:13 Tower avahi-daemon[11847]: Interface veth76f0742.IPv6 no longer relevant for mDNS.
Nov 25 04:00:13 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth76f0742.IPv6 with address fe80::9893:99ff:fed8:fdaf.
Nov 25 04:00:13 Tower kernel: docker0: port 2(veth76f0742) entered disabled state
Nov 25 04:00:13 Tower kernel: device veth76f0742 left promiscuous mode
Nov 25 04:00:13 Tower kernel: docker0: port 2(veth76f0742) entered disabled state
Nov 25 04:00:13 Tower avahi-daemon[11847]: Withdrawing address record for fe80::9893:99ff:fed8:fdaf on veth76f0742.
Nov 25 04:00:13 Tower CA Backup/Restore: docker stop -t 60 Influxdb2
Nov 25 04:00:13 Tower CA Backup/Restore: Stopping jackett
Nov 25 04:00:17 Tower kernel: docker0: port 3(vethf5c6fc1) entered disabled state
Nov 25 04:00:17 Tower kernel: vethcf13e3a: renamed from eth0
Nov 25 04:00:17 Tower avahi-daemon[11847]: Interface vethf5c6fc1.IPv6 no longer relevant for mDNS.
Nov 25 04:00:17 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethf5c6fc1.IPv6 with address fe80::60c6:49ff:fe7b:6cf2.
Nov 25 04:00:17 Tower kernel: docker0: port 3(vethf5c6fc1) entered disabled state
Nov 25 04:00:17 Tower kernel: device vethf5c6fc1 left promiscuous mode
Nov 25 04:00:17 Tower kernel: docker0: port 3(vethf5c6fc1) entered disabled state
Nov 25 04:00:17 Tower avahi-daemon[11847]: Withdrawing address record for fe80::60c6:49ff:fe7b:6cf2 on vethf5c6fc1.
Nov 25 04:00:17 Tower CA Backup/Restore: docker stop -t 60 jackett
Nov 25 04:00:17 Tower CA Backup/Restore: Stopping letsencrypt
Nov 25 04:00:20 Tower kernel: docker0: port 4(veth250f602) entered disabled state
Nov 25 04:00:20 Tower kernel: vethb404b7c: renamed from eth0
Nov 25 04:00:20 Tower avahi-daemon[11847]: Interface veth250f602.IPv6 no longer relevant for mDNS.
Nov 25 04:00:20 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth250f602.IPv6 with address fe80::9836:4bff:fed2:15c0.
Nov 25 04:00:20 Tower kernel: docker0: port 4(veth250f602) entered disabled state
Nov 25 04:00:20 Tower kernel: device veth250f602 left promiscuous mode
Nov 25 04:00:20 Tower kernel: docker0: port 4(veth250f602) entered disabled state
Nov 25 04:00:20 Tower avahi-daemon[11847]: Withdrawing address record for fe80::9836:4bff:fed2:15c0 on veth250f602.
Nov 25 04:00:20 Tower CA Backup/Restore: docker stop -t 60 letsencrypt
Nov 25 04:00:20 Tower CA Backup/Restore: Stopping mariadb
Nov 25 04:00:24 Tower kernel: docker0: port 5(vethae2df10) entered disabled state
Nov 25 04:00:24 Tower kernel: veth03cd18d: renamed from eth0
Nov 25 04:00:24 Tower avahi-daemon[11847]: Interface vethae2df10.IPv6 no longer relevant for mDNS.
Nov 25 04:00:24 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethae2df10.IPv6 with address fe80::2898:ceff:feee:fa04.
Nov 25 04:00:24 Tower kernel: docker0: port 5(vethae2df10) entered disabled state
Nov 25 04:00:24 Tower kernel: device vethae2df10 left promiscuous mode
Nov 25 04:00:24 Tower kernel: docker0: port 5(vethae2df10) entered disabled state
Nov 25 04:00:24 Tower avahi-daemon[11847]: Withdrawing address record for fe80::2898:ceff:feee:fa04 on vethae2df10.
Nov 25 04:00:24 Tower CA Backup/Restore: docker stop -t 60 mariadb
Nov 25 04:00:24 Tower CA Backup/Restore: Stopping MQTT
Nov 25 04:00:24 Tower kernel: veth9d6007a: renamed from eth0
Nov 25 04:00:24 Tower kernel: docker0: port 6(veth847425e) entered disabled state
Nov 25 04:00:24 Tower avahi-daemon[11847]: Interface veth847425e.IPv6 no longer relevant for mDNS.
Nov 25 04:00:24 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth847425e.IPv6 with address fe80::8cdd:a1ff:fee5:7508.
Nov 25 04:00:24 Tower kernel: docker0: port 6(veth847425e) entered disabled state
Nov 25 04:00:24 Tower kernel: device veth847425e left promiscuous mode
Nov 25 04:00:24 Tower kernel: docker0: port 6(veth847425e) entered disabled state
Nov 25 04:00:24 Tower avahi-daemon[11847]: Withdrawing address record for fe80::8cdd:a1ff:fee5:7508 on veth847425e.
Nov 25 04:00:24 Tower CA Backup/Restore: docker stop -t 60 MQTT
Nov 25 04:00:24 Tower CA Backup/Restore: Stopping nextcloud
Nov 25 04:00:28 Tower kernel: docker0: port 7(veth44b9231) entered disabled state
Nov 25 04:00:28 Tower kernel: vethb3c4626: renamed from eth0
Nov 25 04:00:28 Tower avahi-daemon[11847]: Interface veth44b9231.IPv6 no longer relevant for mDNS.
Nov 25 04:00:28 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth44b9231.IPv6 with address fe80::f42f:cff:fea2:dae.
Nov 25 04:00:28 Tower kernel: docker0: port 7(veth44b9231) entered disabled state
Nov 25 04:00:28 Tower kernel: device veth44b9231 left promiscuous mode
Nov 25 04:00:28 Tower kernel: docker0: port 7(veth44b9231) entered disabled state
Nov 25 04:00:28 Tower avahi-daemon[11847]: Withdrawing address record for fe80::f42f:cff:fea2:dae on veth44b9231.
Nov 25 04:00:28 Tower CA Backup/Restore: docker stop -t 60 nextcloud
Nov 25 04:00:28 Tower CA Backup/Restore: Stopping nzbget
Nov 25 04:00:32 Tower kernel: docker0: port 8(veth22d80b0) entered disabled state
Nov 25 04:00:32 Tower kernel: veth1ad5fb5: renamed from eth0
Nov 25 04:00:32 Tower avahi-daemon[11847]: Interface veth22d80b0.IPv6 no longer relevant for mDNS.
Nov 25 04:00:32 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth22d80b0.IPv6 with address fe80::60d3:11ff:fe8f:5971.
Nov 25 04:00:32 Tower kernel: docker0: port 8(veth22d80b0) entered disabled state
Nov 25 04:00:32 Tower kernel: device veth22d80b0 left promiscuous mode
Nov 25 04:00:32 Tower kernel: docker0: port 8(veth22d80b0) entered disabled state
Nov 25 04:00:32 Tower avahi-daemon[11847]: Withdrawing address record for fe80::60d3:11ff:fe8f:5971 on veth22d80b0.
Nov 25 04:00:32 Tower CA Backup/Restore: docker stop -t 60 nzbget
Nov 25 04:00:32 Tower CA Backup/Restore: Stopping nzbhydra2
Nov 25 04:00:37 Tower kernel: docker0: port 9(veth9444825) entered disabled state
Nov 25 04:00:37 Tower kernel: vethcc3e6b8: renamed from eth0
Nov 25 04:00:37 Tower avahi-daemon[11847]: Interface veth9444825.IPv6 no longer relevant for mDNS.
Nov 25 04:00:37 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth9444825.IPv6 with address fe80::183f:64ff:fe8c:e9ff.
Nov 25 04:00:37 Tower kernel: docker0: port 9(veth9444825) entered disabled state
Nov 25 04:00:37 Tower kernel: device veth9444825 left promiscuous mode
Nov 25 04:00:37 Tower kernel: docker0: port 9(veth9444825) entered disabled state
Nov 25 04:00:37 Tower avahi-daemon[11847]: Withdrawing address record for fe80::183f:64ff:fe8c:e9ff on veth9444825.
Nov 25 04:00:37 Tower CA Backup/Restore: docker stop -t 60 nzbhydra2
Nov 25 04:00:37 Tower CA Backup/Restore: Stopping ombi
Nov 25 04:00:41 Tower kernel: docker0: port 10(veth1817c01) entered disabled state
Nov 25 04:00:41 Tower kernel: vethde6851f: renamed from eth0
Nov 25 04:00:41 Tower avahi-daemon[11847]: Interface veth1817c01.IPv6 no longer relevant for mDNS.
Nov 25 04:00:41 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth1817c01.IPv6 with address fe80::60ed:f5ff:fe4b:d5f5.
Nov 25 04:00:41 Tower kernel: docker0: port 10(veth1817c01) entered disabled state
Nov 25 04:00:41 Tower kernel: device veth1817c01 left promiscuous mode
Nov 25 04:00:41 Tower kernel: docker0: port 10(veth1817c01) entered disabled state
Nov 25 04:00:41 Tower avahi-daemon[11847]: Withdrawing address record for fe80::60ed:f5ff:fe4b:d5f5 on veth1817c01.
Nov 25 04:00:41 Tower CA Backup/Restore: docker stop -t 60 ombi
Nov 25 04:00:41 Tower CA Backup/Restore: Stopping Organizr
Nov 25 04:00:45 Tower kernel: docker0: port 11(veth8771336) entered disabled state
Nov 25 04:00:45 Tower kernel: vethf9b0110: renamed from eth0
Nov 25 04:00:45 Tower avahi-daemon[11847]: Interface veth8771336.IPv6 no longer relevant for mDNS.
Nov 25 04:00:45 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth8771336.IPv6 with address fe80::bcf9:c1ff:fe88:9f67.
Nov 25 04:00:45 Tower kernel: docker0: port 11(veth8771336) entered disabled state
Nov 25 04:00:45 Tower kernel: device veth8771336 left promiscuous mode
Nov 25 04:00:45 Tower kernel: docker0: port 11(veth8771336) entered disabled state
Nov 25 04:00:45 Tower avahi-daemon[11847]: Withdrawing address record for fe80::bcf9:c1ff:fe88:9f67 on veth8771336.
Nov 25 04:00:45 Tower CA Backup/Restore: docker stop -t 60 Organizr
Nov 25 04:00:45 Tower CA Backup/Restore: Stopping pihole2
Nov 25 04:00:48 Tower kernel: device br0 left promiscuous mode
Nov 25 04:00:48 Tower kernel: vethb8d4ae9: renamed from eth0
Nov 25 04:00:48 Tower CA Backup/Restore: docker stop -t 60 pihole2
Nov 25 04:00:48 Tower CA Backup/Restore: Stopping qbittorrent
Nov 25 04:00:55 Tower kernel: docker0: port 12(veth2aaf560) entered disabled state
Nov 25 04:00:55 Tower kernel: veth10e20e2: renamed from eth0
Nov 25 04:00:55 Tower avahi-daemon[11847]: Interface veth2aaf560.IPv6 no longer relevant for mDNS.
Nov 25 04:00:55 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth2aaf560.IPv6 with address fe80::400e:64ff:fea4:376c.
Nov 25 04:00:55 Tower kernel: docker0: port 12(veth2aaf560) entered disabled state
Nov 25 04:00:55 Tower kernel: device veth2aaf560 left promiscuous mode
Nov 25 04:00:55 Tower kernel: docker0: port 12(veth2aaf560) entered disabled state
Nov 25 04:00:55 Tower avahi-daemon[11847]: Withdrawing address record for fe80::400e:64ff:fea4:376c on veth2aaf560.
Nov 25 04:00:55 Tower CA Backup/Restore: docker stop -t 60 qbittorrent
Nov 25 04:00:55 Tower CA Backup/Restore: Stopping radarr
Nov 25 04:00:57 Tower root: /etc/libvirt: 73.6 MiB (77156352 bytes) trimmed on /dev/loop3
Nov 25 04:00:57 Tower root: /var/lib/docker: 11.6 GiB (12492013568 bytes) trimmed on /dev/loop2
Nov 25 04:00:57 Tower root: /mnt/cache_nvme: 284.1 GiB (305059872768 bytes) trimmed on /dev/nvme0n1p1
Nov 25 04:00:57 Tower root: /mnt/cache: 11.2 GiB (12015661056 bytes) trimmed on /dev/sdl1
Nov 25 04:00:58 Tower kernel: docker0: port 13(vethbc43fdc) entered disabled state
Nov 25 04:00:58 Tower kernel: veth68b43ca: renamed from eth0
Nov 25 04:00:59 Tower avahi-daemon[11847]: Interface vethbc43fdc.IPv6 no longer relevant for mDNS.
Nov 25 04:00:59 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethbc43fdc.IPv6 with address fe80::e05e:d0ff:fee2:f32d.
Nov 25 04:00:59 Tower kernel: docker0: port 13(vethbc43fdc) entered disabled state
Nov 25 04:00:59 Tower kernel: device vethbc43fdc left promiscuous mode
Nov 25 04:00:59 Tower kernel: docker0: port 13(vethbc43fdc) entered disabled state
Nov 25 04:00:59 Tower avahi-daemon[11847]: Withdrawing address record for fe80::e05e:d0ff:fee2:f32d on vethbc43fdc.
Nov 25 04:00:59 Tower CA Backup/Restore: docker stop -t 60 radarr
Nov 25 04:00:59 Tower CA Backup/Restore: Stopping Sonarr
Nov 25 04:01:02 Tower kernel: docker0: port 14(vethdaa15b7) entered disabled state
Nov 25 04:01:02 Tower kernel: veth7bde32e: renamed from eth0
Nov 25 04:01:02 Tower avahi-daemon[11847]: Interface vethdaa15b7.IPv6 no longer relevant for mDNS.
Nov 25 04:01:02 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethdaa15b7.IPv6 with address fe80::f8d5:88ff:fef1:36e0.
Nov 25 04:01:02 Tower kernel: docker0: port 14(vethdaa15b7) entered disabled state
Nov 25 04:01:02 Tower kernel: device vethdaa15b7 left promiscuous mode
Nov 25 04:01:02 Tower kernel: docker0: port 14(vethdaa15b7) entered disabled state
Nov 25 04:01:02 Tower avahi-daemon[11847]: Withdrawing address record for fe80::f8d5:88ff:fef1:36e0 on vethdaa15b7.
Nov 25 04:01:02 Tower CA Backup/Restore: docker stop -t 60 Sonarr
Nov 25 04:01:02 Tower CA Backup/Restore: Stopping Stash
Nov 25 04:01:02 Tower kernel: docker0: port 15(veth73d1761) entered disabled state
Nov 25 04:01:02 Tower kernel: veth114543d: renamed from eth0
Nov 25 04:01:02 Tower avahi-daemon[11847]: Interface veth73d1761.IPv6 no longer relevant for mDNS.
Nov 25 04:01:02 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth73d1761.IPv6 with address fe80::3487:a4ff:feb2:4c68.
Nov 25 04:01:02 Tower kernel: docker0: port 15(veth73d1761) entered disabled state
Nov 25 04:01:02 Tower kernel: device veth73d1761 left promiscuous mode
Nov 25 04:01:02 Tower kernel: docker0: port 15(veth73d1761) entered disabled state
Nov 25 04:01:02 Tower avahi-daemon[11847]: Withdrawing address record for fe80::3487:a4ff:feb2:4c68 on veth73d1761.
Nov 25 04:01:02 Tower CA Backup/Restore: docker stop -t 60 Stash
Nov 25 04:01:02 Tower CA Backup/Restore: Stopping tautulli
Nov 25 04:01:06 Tower kernel: docker0: port 16(vetha1a9ab9) entered disabled state
Nov 25 04:01:06 Tower kernel: veth31dc015: renamed from eth0
Nov 25 04:01:06 Tower avahi-daemon[11847]: Interface vetha1a9ab9.IPv6 no longer relevant for mDNS.
Nov 25 04:01:06 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vetha1a9ab9.IPv6 with address fe80::5845:1dff:fef8:ed78.
Nov 25 04:01:06 Tower kernel: docker0: port 16(vetha1a9ab9) entered disabled state
Nov 25 04:01:06 Tower kernel: device vetha1a9ab9 left promiscuous mode
Nov 25 04:01:06 Tower kernel: docker0: port 16(vetha1a9ab9) entered disabled state
Nov 25 04:01:06 Tower avahi-daemon[11847]: Withdrawing address record for fe80::5845:1dff:fef8:ed78 on vetha1a9ab9.
Nov 25 04:01:06 Tower CA Backup/Restore: docker stop -t 60 tautulli
Nov 25 04:01:06 Tower CA Backup/Restore: Stopping telegraf
Nov 25 04:01:06 Tower CA Backup/Restore: docker stop -t 60 telegraf
Nov 25 04:01:06 Tower CA Backup/Restore: Stopping unifi-controller
Nov 25 04:01:20 Tower kernel: docker0: port 17(vethdea285a) entered disabled state
Nov 25 04:01:20 Tower kernel: vetha9b79cb: renamed from eth0
Nov 25 04:01:20 Tower avahi-daemon[11847]: Interface vethdea285a.IPv6 no longer relevant for mDNS.
Nov 25 04:01:20 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethdea285a.IPv6 with address fe80::3cfe:83ff:fe44:78c6.
Nov 25 04:01:20 Tower kernel: docker0: port 17(vethdea285a) entered disabled state
Nov 25 04:01:20 Tower kernel: device vethdea285a left promiscuous mode
Nov 25 04:01:20 Tower kernel: docker0: port 17(vethdea285a) entered disabled state
Nov 25 04:01:20 Tower avahi-daemon[11847]: Withdrawing address record for fe80::3cfe:83ff:fe44:78c6 on vethdea285a.
Nov 25 04:01:20 Tower CA Backup/Restore: docker stop -t 60 unifi-controller
Nov 25 04:01:20 Tower CA Backup/Restore: Backing up USB Flash drive config folder to 
Nov 25 04:01:20 Tower CA Backup/Restore: Using command: /usr/bin/rsync  -avXHq --delete  --log-file="/var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log" /boot/ "/mnt/user/B../" > /dev/null 2>&1
Nov 25 04:01:30 Tower CA Backup/Restore: Changing permissions on backup
Nov 25 04:01:30 Tower CA Backup/Restore: Backing up libvirt.img to /mnt/user/Backup/Unraid/librvirt/
Nov 25 04:01:30 Tower CA Backup/Restore: Using Command: /usr/bin/rsync  -avXHq --delete  --log-file="/var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log" "/mnt/user/s../" > /dev/null 2>&1
Nov 25 04:01:32 Tower CA Backup/Restore: Changing permissions on backup
Nov 25 04:01:32 Tower CA Backup/Restore: Backing Up appData from /mnt/cache/appdata/ to /[email protected]
Nov 25 04:01:32 Tower CA Backup/Restore: Appdata not backed up.  Missing source
Nov 25 04:01:32 Tower CA Backup/Restore: Using command: /usr/bin/rsync  -avXHq --delete  --log-file="/var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log" "/mnt/user/s../" > /dev/null 2>&1
Nov 25 04:01:32 Tower CA Backup/Restore: Backup Complete
Nov 25 04:01:32 Tower CA Backup/Restore: Verifying backup
Nov 25 04:01:32 Tower CA Backup/Restore: Using command: cd '/mnt/cache/appdata/' && /usr/bin/tar --diff -C '/mnt/cache/appdata/' -af '/[email protected]' > /var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log & echo $! > /tmp/ca.backup2/tempFiles/verifyInProgress
Nov 25 04:01:32 Tower Docker Auto Update: Community Applications Docker Autoupdate running
Nov 25 04:01:32 Tower Docker Auto Update: Checking for available updates
Nov 25 04:02:22 Tower Docker Auto Update: Installing Updates for Influxdb2 telegraf bazarr binhex-plexpass Grafana GrafanaLoki GrafanaPromtail habridge jackett mariadb MKVToolNix mysql nextcloud nzbget nzbhydra2 ombi Organizr radarr Stash tautulli unifi-controller Dozzle
Nov 25 04:02:28 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup.php update
Nov 25 04:05:25 Tower Docker Auto Update: Community Applications Docker Autoupdate finished
Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered blocking state
Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered disabled state
Nov 25 04:05:26 Tower kernel: device veth103203f entered promiscuous mode
Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered blocking state
Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered forwarding state
Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered disabled state
Nov 25 04:05:26 Tower kernel: eth0: renamed from veth3529a94
Nov 25 04:05:26 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth103203f: link becomes ready
Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered blocking state
Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered forwarding state
Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered blocking state
Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered disabled state
Nov 25 04:05:26 Tower kernel: device vethcbdc85a entered promiscuous mode
Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered blocking state
Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered forwarding state
Nov 25 04:05:26 Tower kernel: eth0: renamed from vethf09dcf8
Nov 25 04:05:26 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethcbdc85a: link becomes ready
Nov 25 04:05:26 Tower kernel: eth0: renamed from veth17417db
Nov 25 04:05:26 Tower kernel: device br0 entered promiscuous mode
Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered blocking state
Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered disabled state
Nov 25 04:05:26 Tower kernel: device veth832e080 entered promiscuous mode
Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered blocking state
Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered forwarding state
Nov 25 04:05:27 Tower kernel: docker0: port 3(veth832e080) entered disabled state
Nov 25 04:05:27 Tower kernel: eth0: renamed from veth6aad366
Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth832e080: link becomes ready
Nov 25 04:05:27 Tower kernel: docker0: port 3(veth832e080) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 3(veth832e080) entered forwarding state
Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered disabled state
Nov 25 04:05:27 Tower kernel: device vethb25ad7c entered promiscuous mode
Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered forwarding state
Nov 25 04:05:27 Tower kernel: eth0: renamed from vetha8162fd
Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb25ad7c: link becomes ready
Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered disabled state
Nov 25 04:05:27 Tower kernel: device veth30aa97a entered promiscuous mode
Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered forwarding state
Nov 25 04:05:27 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth103203f.IPv6 with address fe80::5ceb:7bff:fee3:33dd.
Nov 25 04:05:27 Tower avahi-daemon[11847]: New relevant interface veth103203f.IPv6 for mDNS.
Nov 25 04:05:27 Tower avahi-daemon[11847]: Registering new address record for fe80::5ceb:7bff:fee3:33dd on veth103203f.*.
Nov 25 04:05:27 Tower kernel: eth0: renamed from veth5e50f06
Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth30aa97a: link becomes ready
Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered disabled state
Nov 25 04:05:27 Tower kernel: device vethb48c0f4 entered promiscuous mode
Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered forwarding state
Nov 25 04:05:27 Tower kernel: eth0: renamed from veth0a141e0
Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb48c0f4: link becomes ready
Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered disabled state
Nov 25 04:05:27 Tower kernel: device vethf45d661 entered promiscuous mode
Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered blocking state
Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered forwarding state
Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethcbdc85a.IPv6 with address fe80::b425:3dff:fef3:4d5f.
Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface vethcbdc85a.IPv6 for mDNS.
Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::b425:3dff:fef3:4d5f on vethcbdc85a.*.
Nov 25 04:05:28 Tower kernel: docker0: port 7(vethf45d661) entered disabled state
Nov 25 04:05:28 Tower kernel: eth0: renamed from veth2a444b7
Nov 25 04:05:28 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethf45d661: link becomes ready
Nov 25 04:05:28 Tower kernel: docker0: port 7(vethf45d661) entered blocking state
Nov 25 04:05:28 Tower kernel: docker0: port 7(vethf45d661) entered forwarding state
Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered blocking state
Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered disabled state
Nov 25 04:05:28 Tower kernel: device vethd7d540c entered promiscuous mode
Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered blocking state
Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered forwarding state
Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth832e080.IPv6 with address fe80::d09e:f5ff:fef3:def4.
Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface veth832e080.IPv6 for mDNS.
Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::d09e:f5ff:fef3:def4 on veth832e080.*.
Nov 25 04:05:28 Tower kernel: eth0: renamed from veth09f1eb6
Nov 25 04:05:28 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethd7d540c: link becomes ready
Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered blocking state
Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered disabled state
Nov 25 04:05:28 Tower kernel: device veth8c1d7b3 entered promiscuous mode
Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered blocking state
Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered forwarding state
Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth30aa97a.IPv6 with address fe80::a8ae:c2ff:fe71:b335.
Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface veth30aa97a.IPv6 for mDNS.
Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::a8ae:c2ff:fe71:b335 on veth30aa97a.*.
Nov 25 04:05:28 Tower kernel: eth0: renamed from vethf1a6312
Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethb25ad7c.IPv6 with address fe80::207d:d7ff:fe5b:7669.
Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface vethb25ad7c.IPv6 for mDNS.
Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::207d:d7ff:fe5b:7669 on vethb25ad7c.*.
Nov 25 04:05:28 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth8c1d7b3: link becomes ready
Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered blocking state
Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered disabled state
Nov 25 04:05:29 Tower kernel: device veth5d49058 entered promiscuous mode
Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered blocking state
Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered forwarding state
Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered disabled state
Nov 25 04:05:29 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethb48c0f4.IPv6 with address fe80::1c30:2bff:fe19:c075.
Nov 25 04:05:29 Tower avahi-daemon[11847]: New relevant interface vethb48c0f4.IPv6 for mDNS.
Nov 25 04:05:29 Tower avahi-daemon[11847]: Registering new address record for fe80::1c30:2bff:fe19:c075 on vethb48c0f4.*.
Nov 25 04:05:29 Tower kernel: eth0: renamed from vethbead3ee
Nov 25 04:05:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth5d49058: link becomes ready
Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered blocking state
Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered forwarding state
Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered blocking state
Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered disabled state
Nov 25 04:05:29 Tower kernel: device vethe7a88df entered promiscuous mode
Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered blocking state
Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered forwarding state
Nov 25 04:05:29 Tower kernel: eth0: renamed from veth0de55cc
Nov 25 04:05:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethe7a88df: link becomes ready
Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered blocking state
Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered disabled state
Nov 25 04:05:29 Tower kernel: device veth55df4e5 entered promiscuous mode
Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered blocking state
Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered forwarding state
Nov 25 04:05:29 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethf45d661.IPv6 with address fe80::641c:e0ff:fe7f:a222.
Nov 25 04:05:29 Tower avahi-daemon[11847]: New relevant interface vethf45d661.IPv6 for mDNS.
Nov 25 04:05:29 Tower avahi-daemon[11847]: Registering new address record for fe80::641c:e0ff:fe7f:a222 on vethf45d661.*.
Nov 25 04:05:29 Tower kernel: eth0: renamed from vethc411b47
Nov 25 04:05:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth55df4e5: link becomes ready
Nov 25 04:05:30 Tower kernel: eth0: renamed from veth1d2c254
Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered disabled state
Nov 25 04:05:30 Tower kernel: device veth9ccc506 entered promiscuous mode
Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered forwarding state
Nov 25 04:05:30 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethd7d540c.IPv6 with address fe80::1c74:5ff:fe1c:b306.
Nov 25 04:05:30 Tower avahi-daemon[11847]: New relevant interface vethd7d540c.IPv6 for mDNS.
Nov 25 04:05:30 Tower avahi-daemon[11847]: Registering new address record for fe80::1c74:5ff:fe1c:b306 on vethd7d540c.*.
Nov 25 04:05:30 Tower kernel: eth0: renamed from vethe5c9383
Nov 25 04:05:30 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth9ccc506: link becomes ready
Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered disabled state
Nov 25 04:05:30 Tower kernel: device vethe3bc049 entered promiscuous mode
Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered forwarding state
Nov 25 04:05:30 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth5d49058.IPv6 with address fe80::3805:4bff:fe40:8f4d.
Nov 25 04:05:30 Tower avahi-daemon[11847]: New relevant interface veth5d49058.IPv6 for mDNS.
Nov 25 04:05:30 Tower avahi-daemon[11847]: Registering new address record for fe80::3805:4bff:fe40:8f4d on veth5d49058.*.
Nov 25 04:05:30 Tower kernel: eth0: renamed from veth515d0e6
Nov 25 04:05:30 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethe3bc049: link becomes ready
Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered disabled state
Nov 25 04:05:30 Tower kernel: device veth035980e entered promiscuous mode
Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered forwarding state
Nov 25 04:05:30 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth8c1d7b3.IPv6 with address fe80::45c:42ff:fe29:49e.
Nov 25 04:05:30 Tower avahi-daemon[11847]: New relevant interface veth8c1d7b3.IPv6 for mDNS.
Nov 25 04:05:30 Tower avahi-daemon[11847]: Registering new address record for fe80::45c:42ff:fe29:49e on veth8c1d7b3.*.
Nov 25 04:05:30 Tower kernel: eth0: renamed from veth6afc9d2
Nov 25 04:05:30 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth035980e: link becomes ready
Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered disabled state
Nov 25 04:05:30 Tower kernel: device vethaa3fff4 entered promiscuous mode
Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered blocking state
Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered forwarding state
Nov 25 04:05:31 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethe7a88df.IPv6 with address fe80::8456:99ff:fe30:d08b.
Nov 25 04:05:31 Tower avahi-daemon[11847]: New relevant interface vethe7a88df.IPv6 for mDNS.
Nov 25 04:05:31 Tower avahi-daemon[11847]: Registering new address record for fe80::8456:99ff:fe30:d08b on vethe7a88df.*.
Nov 25 04:05:31 Tower kernel: docker0: port 16(vethaa3fff4) entered disabled state
Nov 25 04:05:31 Tower kernel: eth0: renamed from veth07b4850
Nov 25 04:05:31 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethaa3fff4: link becomes ready
Nov 25 04:05:31 Tower kernel: docker0: port 16(vethaa3fff4) entered blocking state
Nov 25 04:05:31 Tower kernel: docker0: port 16(vethaa3fff4) entered forwarding state
Nov 25 04:05:31 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth55df4e5.IPv6 with address fe80::c09d:a6ff:fead:b0b5.
Nov 25 04:05:31 Tower avahi-daemon[11847]: New relevant interface veth55df4e5.IPv6 for mDNS.
Nov 25 04:05:31 Tower avahi-daemon[11847]: Registering new address record for fe80::c09d:a6ff:fead:b0b5 on veth55df4e5.*.
Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered blocking state
Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered disabled state
Nov 25 04:05:31 Tower kernel: device vethc072768 entered promiscuous mode
Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered blocking state
Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered forwarding state
Nov 25 04:05:32 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethe3bc049.IPv6 with address fe80::a024:d7ff:febf:7d89.
Nov 25 04:05:32 Tower avahi-daemon[11847]: New relevant interface vethe3bc049.IPv6 for mDNS.
Nov 25 04:05:32 Tower avahi-daemon[11847]: Registering new address record for fe80::a024:d7ff:febf:7d89 on vethe3bc049.*.
Nov 25 04:05:32 Tower kernel: eth0: renamed from veth857beb6
Nov 25 04:05:32 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc072768: link becomes ready
Nov 25 04:05:32 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth035980e.IPv6 with address fe80::6c73:bfff:fead:cb03.
Nov 25 04:05:32 Tower avahi-daemon[11847]: New relevant interface veth035980e.IPv6 for mDNS.
Nov 25 04:05:32 Tower avahi-daemon[11847]: Registering new address record for fe80::6c73:bfff:fead:cb03 on veth035980e.*.
Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered blocking state
Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered disabled state
Nov 25 04:05:32 Tower kernel: device veth10c5657 entered promiscuous mode
Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered blocking state
Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered forwarding state
Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered disabled state
Nov 25 04:05:32 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth9ccc506.IPv6 with address fe80::8d8:d5ff:fe40:80e.
Nov 25 04:05:32 Tower avahi-daemon[11847]: New relevant interface veth9ccc506.IPv6 for mDNS.
Nov 25 04:05:32 Tower avahi-daemon[11847]: Registering new address record for fe80::8d8:d5ff:fe40:80e on veth9ccc506.*.
Nov 25 04:05:32 Tower kernel: eth0: renamed from vethe668aab
Nov 25 04:05:32 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth10c5657: link becomes ready
Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered blocking state
Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered forwarding state
Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered blocking state
Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered disabled state
Nov 25 04:05:32 Tower kernel: device vethbb00449 entered promiscuous mode
Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered blocking state
Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered forwarding state
Nov 25 04:05:32 Tower kernel: eth0: renamed from vethf80ec4d
Nov 25 04:05:32 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethbb00449: link becomes ready
Nov 25 04:05:32 Tower CA Backup/Restore: #######################
Nov 25 04:05:32 Tower CA Backup/Restore: appData Backup complete
Nov 25 04:05:32 Tower CA Backup/Restore: #######################

 

 

Edited by Fredrick
Link to comment

Sorry if this has been covered, but how are we supposed to run automated backups of the USB boot drive now?  In 

Appdata Backup/Restore v2 it clearly states, "NOTE: USB Backup is deprecated on Unraid version 6.9.0 It is advised to use the Unraid.net plugin instead."  However, I have searched for this "Unraid.net plugin" in CA with no luck and have googled many variants also with no luck.  What's the deal?  Right now I continue to use Appdata Backup/Restore v2 for USB backup despite the fact that it's deprecated.

 

Thanks,

craigr

  • Like 1
Link to comment

I've noticed that my backups are not including the docker folder. The CA backup command in the logs is odd - it excludes the docker folder with single quotes instead of the double quotes used for folders I've specified. Where is the settings file for CA Backup located? It seems like it has somehow decided to exclude docker but not tell me in the gui.

CA Backup/Restore: Backing Up appData from /mnt/user/appdata/ to /mnt/user/backups/appdata/[email protected]
CA Backup/Restore: Using command: cd '/mnt/user/appdata/' && /usr/bin/tar -cvaf '/mnt/user/backups/appdata/[email protected]/CA_backup.tar.gz' --exclude "mergerfs" --exclude 'docker' * >> /var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log 2>&1 & echo $! > /tmp/ca.backup2/tempFiles/backupInProgress
CA Backup/Restore: Backup Complete
CA Backup/Restore: Verifying backup
CA Backup/Restore: Using command: cd '/mnt/user/appdata/' && /usr/bin/tar --diff -C '/mnt/user/appdata/' -af '/mnt/user/backups/appdata/[email protected]/CA_backup.tar.gz' > /var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log & echo $! > /tmp/ca.backup2/tempFiles/verifyInProgress

 

Edited by hasown
Link to comment
18 hours ago, itimpi said:

There is not much point normally in backing up the Docker folder as its contents can easily be recreated via Apps->Previous apps

 

The point of backing up the docker folder is to backup persistent data that is generated by the containers, not to backup the simple container instructions. You can reinstall a mariadb container from the Apps page, but it won't recreate the database you had previously. The entire reason this plugin stops your containers is so that it can backup the containers' persistent folders in appdata. It even has an advanced option to ignore certain containers that you want to keep running and not backup.

Edited by hasown
Link to comment
On 12/3/2021 at 8:14 AM, hasown said:

 

The point of backing up the docker folder is to backup persistent data that is generated by the containers, not to backup the simple container instructions. You can reinstall a mariadb container from the Apps page, but it won't recreate the database you had previously. The entire reason this plugin stops your containers is so that it can backup the containers' persistent folders in appdata. It even has an advanced option to ignore certain containers that you want to keep running and not backup.

Trying to work out if you are agreeing with me or disagreeing :)

 

You should not normally be storing any persistent data under the docker folder (share) which holds the container binaries - all data to be persisted should be mapped externally to the container (typically to the 'appdata' share')

Link to comment
1 hour ago, itimpi said:

Trying to work out if you are agreeing with me or disagreeing :)

 

Yeah, I can't figure that out either.

 

The way that docker is designed is that everything that can change (or be persistent) should always be outside of the image

 

Any persistent data which you store within the docker image gets overwritten whenever you update the container.  This is the entire point behind why /config mappings etc are mapped outside of the container.

 

A properly designed container (and template) will not store any information required to operate within the image.  The image only contains the static executables etc/

 

Link to comment
On 12/4/2021 at 7:18 AM, itimpi said:

Trying to work out if you are agreeing with me or disagreeing :)

 

You should not normally be storing any persistent data under the docker folder (share) which holds the container binaries - all data to be persisted should be mapped externally to the container (typically to the 'appdata' share')

 

On 12/4/2021 at 8:26 AM, Squid said:

Yeah, I can't figure that out either.

 

The way that docker is designed is that everything that can change (or be persistent) should always be outside of the image

 

Any persistent data which you store within the docker image gets overwritten whenever you update the container.  This is the entire point behind why /config mappings etc are mapped outside of the container.

 

A properly designed container (and template) will not store any information required to operate within the image.  The image only contains the static executables etc/

 

1553103100_Screenshot2021-12-05120222.png.fd1aa6430a2a429d11ae1825a0484370.png

 

I do agree, but I've run into an unintended effect from the above setting. I didn't realize that was happening until yesterday, and unfortunately my previous posts weren't specific enough for you guys to realize what I was doing. I use this folder structure because I also have a /mnt/user/appdata/docker/compose I use to keep track of yamls, and a /mnt/user/appdata/docker/secrets for docker secrets.

 

Presumably this plugin is hardcoded to exclude any folder named docker, regardless of whether it's the system docker directory, which is why my appdata/docker isn't backed up. Can that be changed so that the hardcoded exclude uses /mnt/user/system/docker/, and not just docker? Or ideally, read the exclude path directly from the unraid docker settings, in order to catch any differences in user settings, rare as they might be.

Link to comment
13 hours ago, RBK-Serwer said:

Hi, thx for hard work put to the backup. I got problem to use this app is backup on docker is one file and for me is terrible sollution if one docker broken I cannot restore or just unpack one docker need to restore all. Is possible pack every docker in separate file?

 

Just extract the CA_backup.tar file and you'll have every data folder separately so that you can restore whichever files you want.

  • Like 1
Link to comment

@Squid For those of use that refuse to use the myservers plugin can we please keep the usb backup option =). I am not doubting the merit of the myservers plugin but i cannot be the only one that does not like the direction unraid is going with that plugin. I do not want external telemetry, access, etc. 

 

Note: I am not talking bad or downplaying the myservers plugin I just simply do not want to use it.

Link to comment
On 3/13/2021 at 12:52 PM, Squid said:

USB Flash Drive backup is now deprecated in favour of one of the features (automatic backup of the flash device) present within the Unraid.net plugin when running on Unraid 6.9+

 

This feature will not actually get removed, because there are still use cases for it, but no coding improvements etc will ever happen to this feature.

 

https://forums.unraid.net/topic/104018-my-servers-early-access-plugin/

 

 

  • Like 1
Link to comment

I recently had an issue with my cache drive that caused my docker image to become corrupted. I deleted the image, created a new one, re-installed my apps, and restored appdata from CA Backup. With fairly minor troubleshooting (mostly to recreate a custom network and deal with issues in docker templates that didn't automatically repopulate), everything is working again. Amazing! There's just one exception: Plex refuses to start.

 

Here's the error message I'm getting: 

 

Quote

 

Error: Unable to set up server: sqlite3_statement_backend::prepare: database disk image is malformed for SQL: PRAGMA cache_size=2000 (N4soci10soci_errorE)

 

 

 

 

Why would the database be corrupted if I'm restoring from a perfectly good backup from only ~4 days ago?

 

Edit: while I'd still like to know the answer to the above, I was able to get Plex back up and running using Plex's own database backup by following this: https://support.plex.tv/articles/202485658-restore-a-database-backed-up-via-scheduled-tasks/ 

Edited by randalotto
Link to comment
On 11/17/2021 at 8:01 AM, jademonkee said:

As part of my backup strategy, I use CrashPlan (specifically, this Docker: https://forums.unraid.net/topic/59647-support-djoss-crashplan-pro-aka-crashplan-for-small-business/) to backup the tar.gz output of this plugin to the cloud.

For whatever reason, this takes days to backup to CrashPlan, and - because I run the backup once a month - it means that every month, Crashplan stops backing up my other files for a couple days while this big boy makes its way to the CrashPlan servers.

 

I read a thing recently about the --rsyncable option* in gzip  - is it possible/simple/valuable to add an option to this plugin to support that flag, in the hope** that CrashPlan doesn't have to upload the full 36 GB every month?

Many thanks!

 

*https://beeznest.wordpress.com/2005/02/03/rsyncable-gzip/

**I have no idea if CrashPlan will incrementally upload the same way that rsync would with this flag enabled.

The way I do this is that in CrashPlan I have created a second backup set.  This set is for backing up my backups.  The second is for all my regular files.  Both sets can run at the same time.

Link to comment
3 minutes ago, cjhammel said:

The way I do this is that in CrashPlan I have created a second backup set.  This set is for backing up my backups.  The second is for all my regular files.  Both sets can run at the same time.

This is a great idea. To make a second backup set, do you run a second instance of the Docker, or can you do it all from the same Docker? And if so, how?

Thanks for you help and insight!

Link to comment

Feature Request: @Squid

 

Now that we have multi Cache Pools, I have some Dockers App Data stored on other Cache Drives, I have 3 in total now.

 

Can we get support for Multi Cache Pools where Docker App Data is stored on other Cache Drives.

    Example: I have all my normal AppData stored on my Cache Drive, But then I also have a Plex_AppData stored on a seperate cache drive, and then Nextcloud stored on another seperate Cache Drive as NextCloud_AppData.

 

Then is there a way that when backing up dockers AppData, that only that docker (Or linked dockers, Example we link Nextcould to the database docker) are stopped and then started backup once they are backed up and then start the next docker, so only the docker that is currently being backed up is being stopped, others continue to run until its there time for backing up.

 

Then also make it so we can restore one docker(linked dockers), instead of all or nothing. And if were stopping and starting dockers like I mentioned, then the individual or if linked together are backed into individual backups. by name_date_time. 

 

Since some of use have so many dockers that one backup could be close to 1TB and if we need only one app restored it takes forever, and appdata is only growing.

 

This would allow our dockers to only be down for a short time, just enought for it to be back up and running, and then restore individual backups.

 

Also I would like the ability to back up sets of dockers in schedules,

   Example:

         Daily Backups Mark dockers for daily backups.

         Weekly Backups Mark dockers for weekly backups.

         Monthly Backups Mark dockers for weekly backups.

 

         and an option for backup up marked now!

 

As I don't need all my dockers to backup on the same schedule.  A few I need backed up on a daily basis, then most others done weekly, and a few only monthly.

 

 

My backups can take anywhere from 2-3 hours at times to back up and thats a long time for them all to be down.

 

I know its asking a lot but I feel it would be a huge benefit to the community. 

 

  • Like 5
Link to comment
  • 3 weeks later...

I have three identical Unraid servers.  Each uses syncthing to synchronize all data so that all three are identical.  I use appdata backup to keep all the docker containers backed up and, of course, those backups are synchronized to the other servers.

 

I've seen some requests here to change the single backup file into multiple backup files, one for each container.  I like this not only because it makes sense and would be easier to identify the backup and its app but syncthing doesn't handle large files nicely.  The bigger the file, the longer it takes.

 

https://forum.syncthing.net/t/poor-performance-on-big-file/8934/4

 

Quote

 

calmhJakob BorgSyncthing Maintainer

Jan '17

I don’t think tweaking settings will help you much. There’s a couple of things going on here.

The hasher is parallel and concurrent for multiple files, but any given file is hashed on a single thread. With your six core / twelve thread CPU and how Syncthing (and Windows) shows CPU usage, you should expect to see about 1/12 = 8.3% CPU usage while it’s doing this. 27 minutes is 75*1024/27/60 = 47 MB/s which is a tad on the slow side. I would expect your CPU to do about 150 MB/s or so of hashing so it’s a factor three or so off. The rest is probably overhead, read latency, etc., hard to say. We’re counting on the filesystem doing readahead for us, otherwise the cycle of read-hash-read-hash-etc incurs a couple of milliseconds for each block.

Syncing the file when it has changed goes like this, on the receiving side:

Create a temporary file

Read the previous version of the file and compute weak hashes of the blocks there.

For each block in the file that ought to be the same, copy it while also hashing it and verifying the hash. Uses the weak hashes to find blocks in the old version of the file, otherwise a database lookup to find matching blocks in other files locally.

Pull the blocks that we didn’t find locally from some other device and hash them, write them.

Rename the temporary to the final name.

During the copy phase you’ll see essentially no data flowing, just a few Kbps of index updates. The original file will be read twice; once for weak hashing, and once when copying. It’s too large to fit in disk cache, so this will cause a lot of disk access. Copying the blocks within the same disk will also cause quite a lot of seeks and so on so it’s not a super efficient thing to do for files as large as this.

TL;DR: Large files can be painful.

To find out what it’s doing, if you think it’s CPU or memory allocation related slowness, grab a profile 55. I’ll help interpret it.

 

 

Link to comment
52 minutes ago, TimTheSettler said:

I've seen some requests here to change the single backup file into multiple backup files, one for each container.  I like this not only because it makes sense and would be easier to identify the backup and its app but syncthing doesn't handle large files nicely.  The bigger the file, the longer it takes.

You might want to check out this thread-

https://forums.unraid.net/topic/81233-unraid-671-easy-way-to-backup-and-restore-specific-dockers/

Its what I’ve been using to split them up.

Link to comment

@Squid I need to extract ONE backup file for my Unifi controller that would be in the /mnt/cache/unifi folder from a backup created by this plugin. I keep getting an error when running the command below and even without all the extra tags and also just the folder name itself.  Are ALL my backups crap or am I missing something? I used one of the backups to restore my dockers that is NOT working for this command and I can't seem to extract that either. What am I missing? Does the plugin use another flag or otherwise know how to pull the data? The file is quite large as it includes my plex, radarr and sonarr info. 
 

tar -xzvf CA_backup.tar.gz --ignore-failed-read --exclude="Plex-Media-Server" --exclude="config" --exclude="binhex-radarr" --exclude="binhex-sonarr"

image.png.d6aadd1affc2e9659e10eb4e5b4d1bc8.png

Edited by dja
Link to comment
  • Squid locked this topic
Guest
This topic is now closed to further replies.