I don't know where exactly you're backing up to, but it's taking 6 hours to do the backup itself (finishes around 9am), and then it looks like its taking 2 odd hours to do the verify that you've got selected, then it does appear to restart the containers ~11am

7 hours ago, Squid said:

I don't know where exactly you're backing up to, but it's taking 6 hours to do the backup itself (finishes around 9am), and then it looks like its taking 2 odd hours to do the verify that you've got selected, then it does appear to restart the containers ~11am

It does not restart the containers. I have to restart them manually. Done this two weeks in a row and I've had to restart them manually both times. 

 

It's backing up to the array. Should I be backing it up somewhere else?

This started when I updated to this plugin from the old one.

Edited December 26, 20196 yr by Naonak

On 4/20/2018 at 8:29 AM, Squid said:

No.  Possibility for the future though.

@Squid, my plex library has grown to 500G over the past several years...I'd like to move plex to dedicated drive (ssd - not cache) drive but would like to ensure managed backup...preferably through CA Backup, is this possible yet? I know I can run an rsync and schedule cron, but itd be nice to have it run along with my other backups.

 

Thank you.

On 12/25/2019 at 8:24 PM, Naonak said:

It does not restart the containers. I have to restart them manually. Done this two weeks in a row and I've had to restart them manually both times. 

 

It's backing up to the array. Should I be backing it up somewhere else?

This started when I updated to this plugin from the old one.

Then let it run after it's finished its thing, grab a set of diagnostics and post them without restarting them 

13 hours ago, srfnmnk said:

is this possible yet?

No.  Multiple sources / destinations are not possible

This just wiped out all my Radarr, Medusa, Emby and Ombi installations. I Have had to start from scratch again. No idea what happened after a scheduled backup.

I am looking for some clarification on doing an appdata restore.   Is there a clear order of operations to do the restore?

 

I assume

1.  Stop Docker

2. Erase my appdata directory and information

3. Delete and then recreate appdata the share

4. Erase Docker.img (When do I recreate it?)

5. Do the restore

6. Restart Server

7/ Re-add dockers from previously installed applications  (I am assuming that these docker will be setup exactly as berfore automatically?)

 

Is there a list of clear list of instructions? I picked this out of the General Procedure.  Any input would be great!

 

Pretty much.  You can recreate the docker.img at anytime before 7 and after 4

On 12/31/2019 at 12:55 PM, Squid said:

Pretty much.  You can recreate the docker.img at anytime before 7 and after 4

So looks like I’m going ahead with the restore today.   I assume after step one I would have to uninstall all my dockers first?

Step 4 covers that

I set the plugin to delete any backups older than 5 days old but somehow stopped doing it. I have a total of 30 right now 

 

 

 

Edited January 3, 20206 yr by jrdnlc

5 hours ago, jrdnlc said:

I set the plugin to delete any backups older than 5 days old but somehow stopped doing it. I have a total of 30 right now 

 

 

 

Most likely reason is that an error was returned when backing up.  That prevents any automatic deletion as a safety precaution.  What happens when you manually run a backup?

One of my pooled cache drives died recently (single / JBOD configuration) so I unallocated it, thinking I could just format the other drive without losing anything because I had my appdata backed up and I could just reinstall my dockers. But when I restored the appdata there was nothing there. I then checked my backup folder and sure enough, there's a backup folder there with a date of today, but it was empty. I may have to accept that I'll have to reconfigure all of my dockers, but I would like to find out what I did wrong to make the backup not work.

Here are my settings:

 

If I had to guess it would be that the "delete backups if they are this many days old" setting deleted the last good backup (I don't know why it was set to 1 day), and then the backup this morning failed because the cache drive was already dead. Does that sound right? Does anything else look wrong?

 

Is there any hope for getting my appdata back?

The backup will not run if the source doesn't exist.  If on the other hand the source does exist, then the backup will backup whatever is in there.

Ok thanks, the source must exist then because the backup ran this morning. Does that mean there is an issue with my source setting, since it backed up nothing? Should it have been /mnt/user/appdata/ instead of /mnt/cache/appdata/?

On the shares tab is appdata listed?  /mnt/user/appdata is functionally equivalent to /mnt/cache/appdata for the most part.  You would tend to use whatever is listed in the default appdata folder in Settings - docker

Yes appdata is listed on the shares tab and I can browse to it in windows explorer. The default in Settings - docker is /mnt/user/appdata/ so I'll change the source to that when I set back up.

On 1/3/2020 at 5:42 AM, Squid said:

Most likely reason is that an error was returned when backing up.  That prevents any automatic deletion as a safety precaution.  What happens when you manually run a backup?

 

I think it's because the appdata is being moved to the array. When I try to restore it says "No Backups Sets Found". 

On 1/5/2020 at 8:51 AM, Squid said:

 /mnt/user/appdata is functionally equivalent to /mnt/cache/appdata for the most part.

Not for many people who have somehow gotten parts of appdata onto the array. I seldom look at diagnostics where I don't see appdata and system shares partly on the array. I think many just don't understand the Use cache setting and others set up their dockers before adding cache so that all got created on the array and mover can't move open files so they get stuck on the array even if they have the use cache setting right.

 

I have written many paragraphs about this in multiple threads.

Hi, I lost my cache volume (something went wrong during a disk replace), restored appdata from backup, but all my docker configs were gone.

With lots of effort I recreated each container's config, custom network bridges, environment variables, volume mappings, etc.

 

For docker, the container configs are as important as the appdata, can an option be added to backup and restore container configs along with appdata? (same really applies to VM configs)

 

Edited January 8, 20206 yr by ptr727
spelling

21 minutes ago, ptr727 said:

With lots of effort I recreated each container's config, custom network bridges, environment variables, volume mappings, etc.

 

For docker, the container configs are as important as the appdata, can an option be added to backup and restore container configs along with appdata?

These are already saved on flash, and you can reuse them without going to all that trouble of setting each one up again. The simplest way is to just use the Previous Apps feature on the Apps page.

8 minutes ago, trurl said:

These are already saved on flash, and you can reuse them without going to all that trouble of setting each one up again. The simplest way is to just use the Previous Apps feature on the Apps page.

The config may have been on the flash before, but after losing the cache, restoring it, there is no docker config, and bringing back the apps, leaves them with default configs, not the old config.

Previous apps makes it easier to see what I previously installed, to my knowledge it does not have a copy of the old config.

Yes, I could restore the flash with appdata, or I could manually copy config files (I don't even know where to start), or ... the backup app can do it for me.

7 minutes ago, ptr727 said:

Previous apps makes it easier to see what I previously installed, to my knowledge it does not have a copy of the old config

The Previous Apps option DOES have the settings last used if you re-install a docker container from there (assuming you mean all the mapping of shares, ports etc).

 

5 minutes ago, ptr727 said:

Previous apps makes it easier to see what I previously installed, to my knowledge it does not have a copy of the old config.

Your knowledge is incomplete. It does have a copy of the old config because it is on flash and it goes to flash and gets it and uses it to reinstall your docker just as it was.

13 minutes ago, trurl said:

Your knowledge is incomplete. It does have a copy of the old config because it is on flash and it goes to flash and gets it and uses it to reinstall your docker just as it was.

Thanks, wish I'd known that (I bet many people don't, and like me they may look for it in the backup / restore section).

But, there is no history of any of my docker hub only containers, there is also no historic versioning (or am I going to find it when I try to use it), so I still think it would be a good idea to implement docker (and maybe VM) config backup and restore along with the appdata used by the containers.