Is there a way to specify multiple backup locations? In other words, I want to backup to both a location in my array and to a drive that I have mounted using unassigned devices.

I would thing the simplest thing would be to have a "Post-run script" copy the backup file once it is complete.  Certainly would have less risk of problems from trying to create two compressed archives at the same time.

 

The debug log contains all infos needed.

 

the backup stops logging at the part where extra files should back up. Either the backup script crashes or its still running? No, when running, no sharing possible afaik.

 

And just by checking the code block for this task reveals the bug. Its a typo.

 

Ill try to fix it today.

thx a lot finding/fixing the issue!

Just let me know when it's online, i am here to test.

Just now.

1 hour ago, KluthR said:

Just now.

 

Thanks, working as expected with one folder in extra files.

Will add a second later, but will also expect, that it works.

Hugh thanks!

I installed the update today. My entire appdata is reset, my entire MariaDB Nextcloud Bookstack, Nginx everything is back to 0, how do I restore this from old backups? I just installed it never set anything and just did the update today too

and all Backups are gone too

 

Edited September 25, 20241 yr by till_bx
new information

It's likely completely unrelated,. check if your drives are actually mounting correctly.

2 hours ago, Kilrah said:

It's likely completely unrelated,. check if your drives are actually mounting correctly.

Just what I thought. 

beta 2 v7 this is a new error:
Shared debug report ID
084722d5-c3aa-484e-b679-ad122196d03e

 

 

diag.zip

Update to latest.

Good Morning,

 

Looking for some guidnace on an issue I spotted this morning.

 

See Screenshot:

 

I have a delay set for most of my containers as my server is running an N100 CPU, I have around 30 containers and starting them all at once usually results in some items not starting correctly. if I reboot the server the start up sequence is fine (Due to the delays)

 

The issue I have only started happening in the last few days, I noticed my GITEA server is down most morning and it looks like when the container starts the databaase is not ready as its still starting, my delays define there should be 2-3 minutes between the DB starting and the GITEA container starting.

 

I am finding during the back up it is stated in the log regarding the delays but the delays dont actually happen, see time stamp on the left hand side.

 

Is it expected that the delay will not work during the back up?

 

I dont see any issue. The timestamps are correct (+10 seconds)??

1 hour ago, KluthR said:

I dont see any issue. The timestamps are correct (+10 seconds)??

 

 

yep, seems you are right, I must have mistaken the minutes for seconds when looking at the issue this morning (Before the coffee kicked in), will need to revisit it again tomorrow morning, seems to be the last 3-4 days druing the back up my GITEA instance has been stuck in a stopped state.

 

The logs for GITEA show the database is not available, the container starts tries to connect to the DB 10 times then dies, but the database instance is up, I just start the GITEA container and it starts fine so something strange happening during the back up so will revisit it tomorrow morning, sorry to have wasted you time here!

Edited September 27, 20241 yr by DeekB
correcting some typos

No problem 😁

On 9/9/2024 at 5:21 PM, pfdt said:

 

Hello KluthR, ok I will do a docker ps -a next time. But it it helps : when it happened I can easily start the stopped containers in the Unraid UI.

 

 

 

Thank you Kilrah, I've checked and yes : PIA have been updated the last times.

 

I've made a couple of test and discovered that no : the problem doesn't occur every time. My 2 manual backups of the day finished without any problem.

 

So the update of the vpn container is a good lead...

 

 

 

 

 

Hello I'm back with my vpn update problem (here is my first post about it).

The recent backups went well but yesterday it failed due to the vpn container update. So the problem is definitely here.

 

But I've checked the container id using "docker ps -a" and it is the same before and after the update.

 

I don't know if it can be fixed. For now I have disabled the auto update for this container.

Probably more of a feature request, but any possibility of adding an option (maybe behind a "Yes I really know what I'm doing" checkbox) to backup the appdata without stopping containers?

 

The use case would be where you're using a filesystem that can support snapshots like BTRFS or ZFS, nominally on a cachepool. In my case I could use ZFS so could use the pre/post backup scripts to take a quick snapshot of the appdata filesystem, then direct the backups to only backup the /mnt/user/appdata/.zfs/snapshot/$snapname directory then delete the snapshot when done.

 

While stopping the containers isn't a huge deal for me there are a couple I prefer not to stop and leave in the skip bucket right now. This would enable me to take a "crash-consistent" backup of those containers that'd be great for restoration in a crunch. This would be amazing for database containers for example or containers that run long-running jobs you don't want to stop.

You mean like this, in Show advanced options?

 

Yup.... exactly like that. Thank you for your prescience...

Hello there,

 

This issue happens only sometimes, like once every 10/15 backups.

 

I have a container that is a VPN tunnel, PIA. There are 3 other containers that have Network Type: Custom container:pia

 

The VPN container starts always first. When the other 3 start after the backup, they fail, as they are looking for a container id for their network and this has changed. I have a stupid fix in place in the post-run script that checks if the containers are running or not, and then executes the whole docker run, as it is displayed when starting from the UI. They come up without an issue.

 

if docker ps --filter "name=thelounge" --filter "status=running" | grep -q "thelounge"; then echo -e "Container thelounge is running\n" else echo -e "Container thelounge is not running.\n" /usr/bin/docker remove thelounge /usr/bin/docker run -d --name='thelounge' --net='container:pia' [...]'

 

Since I have this fix in my script I don't have issues anymore, other than the red notifications when it happens. I wanted to bring attention to it.

 

Thank you for the development efforts. The plugin is staple for me.

 

Debug log ID: 4b60e7f5-421c-45b4-abcf-74730e670f60

 

Issue in Github: https://github.com/Commifreak/unraid-appdata.backup/issues/38

25 minutes ago, ANIMATEK said:

This issue happens only sometimes, like once every 10/15 backups.

Have you set the plugin to auto-update containers? If so don't in a setting with container dependencies, as there have been some posts just above lately if the vpn container gets updated then all depending containers have to be recreated. The error likely happens every time there's an update.

I just wanted to report an issue that I had today with the Backup Appdata plugin. I was replacing my cache drive so used the backup/restore functions of the Backup Appdata plugin as part of the process. Most everything worked, but I had a minor issue with the restore for the Channels DVR Docker container. Apparently, Channels DVR downloads some binaries into a folder within it's appdata folder. The name of the folder is the same as the current version of Channels DVR. It then creates a symbolic link to that folder and calls it "latest". When I restored from backup, some of these folders ended up being empty and caused issues with Channels DVR.

I saw another post here with similar issues with Plex and symbolic links, but figured I would also report the issue I had. It doesn't look like the plugin properly handles symbolic links.

Hello,

 

I was reviewing my backups and noticed they had a failed at the tail of the file backup folders. I looked at the log and saw the following error: 

 

An error occurred during backup! RETENTION WILL NOT BE CHECKED! Please review the log. If you need further assistance, ask in the support forum.

 

This to happen after the Flash backup is created.

 

I have attached the most recent backup log. Please assist. 

 

 

backup.debug.log

If you read the output verification failed for container tautulli, make sure any containers sharing data are in a group.

Okay. I look to have figured out how to group. Thank you. 

Edited October 4, 20241 yr by cpom1