Container appdata from ZFS Snapshots is not found

dpremy commented 11 months ago

Essentially, it seems the logic for finding the Internal appdata directories doesn't account for changes to the root path, say when using a ZFS snapshot.

I think this could be recreated without ZFS by copying appdata to any other location, and then using that copied location as the source of the backups in the plugin, but I've not verified this.

I suspect the issue is in isVolumeWithinAppdata and the str_starts_with. PHP isn't my forte, though I'll see if I can do some testing and get working code.

As an aside, a little additional debug logging in isVolumeWithinAppdata would help surface this, right before the if, and possibly an else to log unmatched volumes.

Recreating Issue

Create a ZFS Pool which hosts the appdata directory

# zfs list pool-one/appdata
NAME               USED  AVAIL     REFER  MOUNTPOINT
pool-one/appdata   167G  1.15T      167G  /mnt/pool-one/appdata

Use a Pre-backup script to take a ZFS snapshot with a static name. In my case, I destroy any previous offline-backup snapshot, then create a new snapshot; keeping previous snapshots of this name are not needed.
```
$ cat create-zfs-snapshot.sh
#!/usr/bin/env bash

zfs destroy pool-one/appdata@offline-backup
zfs snapshot pool-one/appdata@offline-backup
exit 0
```

Verify the snapshot was created

# zfs list -t snapshot pool-one/appdata
NAME                              USED  AVAIL     REFER  MOUNTPOINT
pool-one/appdata@offline-backup   217M      -      167G  -

Confirm the snapshot can be accessed

ls /mnt/user/appdata/.zfs/snapshot/offline-backup
Set the Appdata source in the plugin to this snapshot location of /mnt/user/appdata/.zfs/snapshot/offline-backup

All containers now have no Internal Volumes in the Per container settings, and reviewing a backup log you will find related messages

Logs

Standard

[01.01.2024 09:49:06][ℹ️][Gitea] Stopping Gitea... done! (took 1 seconds)
[01.01.2024 09:49:07][ℹ️][Main] Starting backup for containers
[01.01.2024 09:49:07][ℹ️][Gitea] Should NOT backup external volumes, sanitizing them...
[01.01.2024 09:49:07][ℹ️][Gitea] Gitea does not have any volume to back up! Skipping

Debug

[01.01.2024 09:49:06][▒.▒▒.][MGitea] Stopping Gitea...  done! (took 1 seconds)
[01.01.2024 09:49:07][▒.▒▒.][Main] BStarting backup for containers
[01.01.2024 09:49:07][debug][Gitea] Backup Gitea - Container Volumeinfo: Array
(
    [0] => /mnt/user/appdata/gitea:/data:rw
)

[01.01.2024 09:49:07][debug][Gitea] usorted volumes: Array
(
    [0] => /mnt/user/appdata/gitea
)

[01.01.2024 09:49:07][▒.▒▒.][Gitea] Should NOT backup external volumes, sanitizing them...
[01.01.2024 09:49:07][▒.▒▒.][Gitea] Gitea does not have any volume to back up! Skipping

Commifreak commented 11 months ago

Yes, setting the path to a snapshot will not change anything thats stored inside the container template. Those paths are still the "normal" ones.

I dont know if the plugin should handle this or if another solution for backing up zfs snaps is better.

dpremy commented 11 months ago

I understand the hesitation. ZFS is newer to unRAID, likely a small subset of users need this, and if you aren't careful, it could expand in scope quickly. While this could be reproduced with a copy/sync of some sort, via a pre-backup script, that too seems like a rare edge case.

On the flip side, supporting something like this could take the time containers are stopped from hours/minutes, to under 10 seconds. Advanced usage, yes, but significant returns for larger containers.

In my use case I do have a container which is a few gb, and backups take nearly an hour. With current options in the plugin, the container is down during backup. If this snapshot method is supported for Internal and External volumes, I could have the container restarted in a matter of seconds, and then just backup the volumes as time permits.

I believe this could be supported with a few changes:

In Backup Types add an option to 'Stop all containers, pre-backup script, start containers, backup', with a comment that this requires a script to snapshot, copy or sync the data before backup.
If this option is selected, add an Appdata Offline Copy field
String replace Appdata Sources and Appdata Offline Copy in isVolumeWithinAppdata and the backup stage

Commifreak commented 11 months ago

Maybe a simple native zfs snapshot support would be sufficient? The plugin could stop all containers, create a snapshot, start all containers and doing its backup by adjusting the paths.

Commifreak commented 4 months ago

FTR:

https://forums.unraid.net/topic/137710-plugin-appdatabackup/?do=findComment&comment=1378995 (and the one below)

So, this ticket is about ZFS snapshot support, if docker uses a zfs storage.

The plugin neds to:

Stop every container
Create snapshot
Start containers
Backup the just created snapshot
Done

Right?

Commifreak / unraid-appdata.backup