5 hours ago, 128bytes said:

Woudl be great if this can be looked at as it appears in this forum for a while already

This is no issue with the plugin. Somehow tar thinks the file shrank, so I assume some kind of access and/or filesystem issues. Could you do a filesystem check?

13 hours ago, KluthR said:

This is no issue with the plugin. Somehow tar thinks the file shrank, so I assume some kind of access and/or filesystem issues. Could you do a filesystem check?

What cmd would you like me to run on it?

Is there a way to dump the backup files into a standard dir and not into a date appended dir?

[27.05.2025 09:42:13][][Main]  WELCOME TO APPDATA.BACKUP!! :D
[27.05.2025 09:42:13][][Main] Backing up from: /mnt/user/appdata, /mnt/cache/appdata
[27.05.2025 09:42:13][][Main] Backing up to: /mnt/user/backups/ab_20250527_094213
[27.05.2025 09:42:13][][Main] Cannot create destination folder!
[27.05.2025 09:42:20][][Main] Checking retention...
[27.05.2025 09:42:20][][Main] DONE! Thanks for using this plugin and have a safe day ;)
[27.05.2025 09:42:20][][Main] 

Have gotten this error about not being able to create the destination folder for a couple weeks now. Nothing obvious sticks out to me--there should be plenty of space available on the array in the /user/backups/ share, no disks excluded from that share, and I don't see anything in the unraid syslog that provides further context.

I submitted the plugin debug log at 225e0926-27d8-450d-82c4-bf6a243c5643 and would appreciate any help in diagnosing

Try creating a folder via terminal (mkdir) there. Check the rights (ls -la /user/backups) for that folder.

Sanity check here: my backup share (and destination for this plugin) is mapped to my Duplicacy container for obvious reasons. I need to exclude that backup share in AppdataBackup so it doesn't make backups of my backups, correct? Because the plugin goes after each and every mapping that's in containers' settings...

Edit: Hm, I'm probably wrong here. As the backups folder is not listed as a location for appdata, it should be skipped by default. That's not what happened, instead I got an error that the location mapped to Duplicacy was not found (expected, I had just renamed the appdatabackup share to backups because it is going to hold more than just appdata backups, but this change has not yet made it into the Duplicacy container settings). That's likely because it checks to see if a mapped location exists at all before it determines whether it's inside or outside the appdata folder.

So backups as a share is now excluded, but that's not making any difference as even when /backups/ is discovered as an actual existing location, it will be skipped because it's outside the regular appdata location.

Edit2: after much more backup tweaking, I'm confident edit 1 is correct.

As others have said, it would be excellent to be able to have this plugin just copy files over to the backup destination without any archiving. That way Duplicacy and other incremental backup apps can save absolute tons of space in the cloud.

Right now if I want incremental backups, I need to give Duplicacy access to /appdata/ and /boot/config and cut out Appdatabackup entirely. Shame, because other than the lack of a 'do not archive' function it is packed with excellent features, like stopping and starting containers and backing up the flash drive.

Home Assistant does it too with its backups - it always archives them. Luckily the HA backup by itself is not that huge, at least in my modest case.

Edit3: as I learn, I realize nothing I said here is relevant. Uncompressed .tar files are compatible with Duplicacy's deduplication tech so appdatabackup is fine the way it is. Just need to convert the flash drive backup from zip to tar before Duplicacy does its thing.

Edited May 29, 20251 yr by thatsthefrickenlightning

On 2/7/2024 at 10:14 AM, SirCadian said:

OK.  Last night's backup went through as expected.

2024-02-07 06:45:58.617 INFO BACKUP_STATS Files: 65 total, 81,341M bytes; 65 new, 81,341M bytes
2024-02-07 06:45:58.617 INFO BACKUP_STATS File chunks: 12739 total, 81,341M bytes; 792 new, 4,772M bytes, 3,009M bytes uploaded
2024-02-07 06:45:58.617 INFO BACKUP_STATS Metadata chunks: 4 total, 943K bytes; 4 new, 943K bytes, 723K bytes uploaded
2024-02-07 06:45:58.617 INFO BACKUP_STATS All chunks: 12743 total, 81,342M bytes; 796 new, 4,773M bytes, 3,010M bytes uploaded
2024-02-07 06:45:58.617 INFO BACKUP_STATS Total running time: 00:15:55

Duplicacy is definitely de-duplicating and only uploading changed chunks.  Upload last night was around 4% of the total backup size.  Duplicacy is also compressing the uncompressed data on upload so it takes ~50% less space in the remote bucket.

 

I'll likely still only run this once a week as I have copies held both locally on the array and on my local PC (once daily, a user script waits until it sees Unraid mount a remote share on my PC and then copies the local backups across).  Now I just need to have a think about VM backup, particularly my Home Assistant instance...really don't fancy having to rebuild that from scratch in the event of a catastrophic failure.

Hope I'm not being a horrible necro here, but if .tar files are perfectly compatible with Duplicacy's deduplication feature, then there's no real need for a 'backup as plain files and folders' feature, right?

All we'd need then is a post-appdatabackup script that converts the flash drive backup from its current .zip format to .tar and it too can be backed up with deduplication.

On 5/13/2025 at 8:06 AM, mil4N said:

Before, the named volume wasn't even taken into account:

[07.05.2025 03:27:37][][immich_machine_learning] Should NOT backup external volumes, sanitizing them...
[07.05.2025 03:27:37][][immich_machine_learning] immich_machine_learning does not have any volume to back up! Skipping. Please consider ignoring this container.

Nevertheless, how to properly exluce those from backup then? 

Set the container to 

 

Skip backup? Only stop/start

 => Yes, skip backup and do stop/start only 

 

Still, the error was thrown.

[13.05.2025 03:24:39][❌][immich_machine_learning] 'immich_model-cache' does NOT exist! Please check your mappings! Skipping it for now.
[13.05.2025 03:24:40][ℹ️][immich_machine_learning] Should NOT backup this container at all. Only include it in stop/start. Skipping backup...

 

Hi, I have the same problem. Did you solved it?

Have a weird new error. Relevant log snippet:

[31.05.2025 15:23:07][debug][Main] Docker update check finished!
[31.05.2025 15:23:07][debug][Main] Planned container updates:
[31.05.2025 15:23:07][debug][Main] Not executing script: Not set!
[31.05.2025 15:23:07][debug][Main] unraid\plugins\AppdataBackup\ABHelper::doBackupMethod: $containerListOverride:
[31.05.2025 15:23:07][ℹ️][Main] Method: Stop all container before continuing.
[31.05.2025 15:23:07][ℹ️][nextcloud] Stopping nextcloud... Error while stopping container! Code: Container already started - trying 'docker stop' method
[31.05.2025 15:23:07][ℹ️][nextcloud] That _seemed_ to work.
[31.05.2025 15:23:07][ℹ️][Main] Starting backup for containers

The thing is, I stop several containers with a pre-run script before AB does anything. At this point, Nextcloud is already stopped (verified in webUI Docker tab). The log, however, says Nextcloud has 'already started', which is weird because A: AB is trying to stop it, not start it, and B: the 'docker stop' method is the same method the script has successfully used at this point to stop this container.

Because AB thinks Nextcloud is running and needs stopping, it restarts the container after all is done, which I need it to not do for the sake of other backup actions that take place after AB is done.

If someone can help, I would massively appreciate it. Been working to get decent Unraid cloud backups off the ground for a week now. Hell @KluthR or anyone else there's a donation in it for you if you can help. (if that's against the rules, sorry and I'll delete it)

Edited May 31, 20251 yr by thatsthefrickenlightning

@thatsthefrickenlightning Thats interesting, because:

• The status informations about all containers are checked AFTER the prerun script. So, if you are stopping any container, the script should be aware of it.

• The mentioned log-line contains messages directly from docker. The "Code: " is from me, anything betweenthat and " - trying docker stop method" is the result that docker said to me.

• Also, the stop routine checks, if the current container is Not Paused and Running and only issues a stop then.

Can you verify, that your pre-run script really stops the container in question? If yes, please submit a full debug log. The debug log contains all container states after the pre-run script.

Is there a way to prevent certain containers from being restarted after the backup? I have a script that handles about half of my containers in a specific way but I still want them backed up. Currently when those containers are started with the plugin they fail to start and the backup generates errors.

Did you tried „Skip stopping of container“? Im not sure if this skips start as well.

I have not but I guess that could work. I don't "think" backing up the data would be affected if the container is running. It does say "NOT RECOMMENDED" next to that option. What are the implications of setting that?

8 hours ago, Milspeccqb said:

It does say "NOT RECOMMENDED" next to that option. What are the implications of setting that?

Files may change in the middle of the backup and result in an inconsistent/useless backup.

If they don't start it sounds like there may be dependencies on others so you should probably use the group feature. Or handle stopping in your scripts.

On 5/31/2025 at 8:03 PM, KluthR said:

@thatsthefrickenlightning Thats interesting, because:

• The status informations about all containers are checked AFTER the prerun script. So, if you are stopping any container, the script should be aware of it.

• The mentioned log-line contains messages directly from docker. The "Code: " is from me, anything betweenthat and " - trying docker stop method" is the result that docker said to me.

• Also, the stop routine checks, if the current container is Not Paused and Running and only issues a stop then.

Can you verify, that your pre-run script really stops the container in question? If yes, please submit a full debug log. The debug log contains all container states after the pre-run script.

Sure, I've sent in a debug log to you. ID is 0657fbea-1329-4e95-9ded-98d0d3c42229. Very grateful.

Edited June 2, 20251 yr by thatsthefrickenlightning

Thanks. Why dont you use the grouping feature inside the plugin? However - your script says, it stopped nextcloud. But the status information afterwards show, that nextcloud is still running. Same for immich.

Checking the code again shows me, that I get the container statuas AFTER the preun script. Can you verify your script really stopped the containers in question? It shows that it tried to - but did it succeeded? Is the docker stop exit code being checked? You could add a docker ps in your script for debug purpose to see which container is in which state.

On 5/26/2025 at 6:49 PM, dgallaher said:

[27.05.2025 09:42:13][][Main]  WELCOME TO APPDATA.BACKUP!! :D
[27.05.2025 09:42:13][][Main] Backing up from: /mnt/user/appdata, /mnt/cache/appdata
[27.05.2025 09:42:13][][Main] Backing up to: /mnt/user/backups/ab_20250527_094213
[27.05.2025 09:42:13][][Main] Cannot create destination folder!
[27.05.2025 09:42:20][][Main] Checking retention...
[27.05.2025 09:42:20][][Main] DONE! Thanks for using this plugin and have a safe day ;)
[27.05.2025 09:42:20][][Main] 

Have gotten this error about not being able to create the destination folder for a couple weeks now. Nothing obvious sticks out to me--there should be plenty of space available on the array in the /user/backups/ share, no disks excluded from that share, and I don't see anything in the unraid syslog that provides further context.

I submitted the plugin debug log at 225e0926-27d8-450d-82c4-bf6a243c5643 and would appreciate any help in diagnosing

I'm having the same problem. Did you find a solution?

4 hours ago, KluthR said:

Thanks. Why dont you use the grouping feature inside the plugin? However - your script says, it stopped nextcloud. But the status information afterwards show, that nextcloud is still running. Same for immich.

Checking the code again shows me, that I get the container statuas AFTER the preun script. Can you verify your script really stopped the containers in question? It shows that it tried to - but did it succeeded? Is the docker stop exit code being checked? You could add a docker ps in your script for debug purpose to see which container is in which state.

I don't use grouping because the idea is for those containers to stay stopped after AB is done, and this is the suggested way to do that. I want this because after AB is done, Duplicacy backs up the non-appdata folders for Nextcloud and Immich. I don't want them restarted before Duplicacy does its thing because then the backed up databases will lag behind those folders if anything gets changed in the interim, which could give me headaches I'd really like to avoid.

The script really stops the containers. The Docker page shows 'exited (0) xx seconds ago' after I ran it just now.

I'll vibe code in a check to have it echo the stop exit code (and some more stuff maybe) and get back to you.

Edit: @alan7467 troubleshooting it as we speak

Edited June 2, 20251 yr by thatsthefrickenlightning

On 6/2/2025 at 7:27 AM, alan7467 said:

I'm having the same problem. Did you find a solution?

I figured out my problem. Was hitting the minimum disk space on my share. Adjusted that setting, and I’m off to the races.

On 6/2/2025 at 7:27 AM, alan7467 said:

I'm having the same problem. Did you find a solution?

I figured out my problem. Was hitting the minimum disk space on my share. Durp.

I only use manual backup, I don't use scheduled backup. Would it be possible to add a shortcut to make a manual backup? Does the same happen with the manual move button? It would save a lot of effort

Shortcut? Where?

What do you mean with manual move button?

6 hours ago, KluthR said:

Atalho? Onde?

O que você quer dizer com botão de movimentação manual?

something like this

Hm. Dont know if plugins are able to register a button there. But a dashboard tile should be possible.

I've had two issues with this plugin since updating to unRAID 7.1.2.

I'm on version 2024.11.21.

The first issue was with a Docker app not backing up.

I was able to resolve that issue.

The second issue continues to be a problem that I can't resolve.

The error is:

[MAIN] Copying flash backup to destination failed!

The error only happens when Auto Backups are run.

This error does not happen if I Manually Backup.

My flash backups are copied to a custom destination, which is an Unassigned Disk.

The drive has no errors, is available under SMB, and formatted as NTFS.

I've been using this same drive for years with no issues.

Also, the CA backup folder was never created on my array share.

So I don't have a folder under CA Backups/7.1.2/backups/ that shows as ab_20250609_060001-failed.

Does anyone have an idea of what is going on?

I've attached the unRAID diagnostics and here is the Appdata Backup ID: 90980e6b-4bde-496d-ad2a-81e4862ba041

myers19-diagnostics-20250609-1239.zip

Hi,

I'm running into an issue every time I run this. I have a compose file that has some depends, and appdatabackup always restarts apps in alphabetical order. Even with those in my compose files. My debug log is "2e2a3985-683a-49af-b828-44a7823113be"

In that log, you can see bouncer-traefik is not starting, but it's not starting because it depends on traefik first. Which is towards the end of the start sequence using this plugin. Is there a way to just start single docker containers, and then start compose' stacks as a whole stack?

*edit*

Just saw the start order section. This works!

Edited June 10, 20251 yr by Blaze9