Disaster Recovery Plan Help

The main purpose of the plugin's backup utility is to provide the user with a consistent copy of persistent container data. With that goal in mind, this utility is designed to stop the containers, backup the stopped containers, and then start the containers again. All this is done automatically as you already know. And what the compose plugin actually does is a synchronization with rsync.

The key is the phrase "stop the containers."

If you were to back up the containers with any specialized backup application without stopping the containers you would have a backup that could probably be inconsistent.

So what you should do at that moment is use any specialized backup application to, now, make a compressed, versioned backup, etc. of the folder that the plugin generated. That same application is the one that should help you restore the backed up data.

I personally do that with Duplicati, but you can use whatever app you want, or the openmediavault-borgbackup plugin.

Regarding Nextcloud AIO, you should keep in mind that it is a somewhat special container. It is actually a container that manages other containers, something similar to Portainer (on a much smaller scale). Nextcloud AIO generates volumes in the docker folder that are not being backed up by the compose plugin. But Nextcloud AIO has in its GUI an easily configurable automatic backup utility (it uses borgbakup internally) that does something similar to the compose plugin. Stops Nextcloud AIO containers, backups them, and restarts them.

I also use Nextcloud AIO, what I do is include the backup that Nextcloud AIO generates in my regular Duplicati backups along with the persistent data that the plugin's backup utility provides me.

In addition to everything I just told you, you have a Restore tab in the plugin that is not yet explained in the wiki but that allows you to restore from the backup generated by the plugin. If you have questions about the operation of that tab, ask them here.

And with respect to your particular case, to have the two servers synchronized, I think you need something more than all this. Everything I have mentioned are backups and I think what you need are synchronizations.

A reasonable way to do this might be to stop the docker service, sync all docker data with rsync between the two servers, and restart the docker service. This way the two servers would always have the same data in the containers. But there's nothing I know of that does that automatically. You would need to make a script I think.

To sync data shares between your servers and to create a backup server, take a look at the remote mount -> doc. At the end of the doc, it will refer you to another (OMV5) document that discusses the in's and out's of creating a fully functional backup server that will be ready to go at a moments notice.

notnormalnerd

Note that the procedure outlined by crashtest will work for shared data folders, but will not solve the synchronization of persistent data from containers and docker volumes created by Nextcloud AIO in the docker folder. To synchronize that type of data you must stop docker, as I already said, and then start it again. That's why you would need a script that does that job automatically. Or do it manually.

It all depends on the downtime you can afford and the need for redundancy in the data you have.

In my case I only need redundancy in the documents since my work documents are there, so a ZFS Raid guarantees the integrity of that data and guarantees that I will not lose a day's work until the next backup is made .

Regarding the rest, if the server fails I can assume downtime. The worst scenarios could be a theft or fire in my house and the main and backup servers disappearing at the same time. Or a malware infection and end up with your data encrypted. In those cases I would have to recover data from a remote server where I also make backups. From the remote backup server you could redo everything as it was again assuming the time it takes to redo some configurations and recover data from the backup.

If you can't afford even five minutes of inactivity, you need much more, we go beyond what is understood by a home server. Syncing all data does not protect you from malware, for example. For that you need versioned backups and would need restore time.

Zitat von notnormalnerd

I am confused as the plugin and docs seem to contradict each other.

Well. There are differences of, I don't know what to call it, interpretation? between the one who programs the plugin, ryecoaaron , and the one who writes that document, me

ryecoaaron wants that data folder to be used for persistent data and that's why in the GUI it is written like this. The approach would be a folder for persistent data independent of the compose folder in which only the yml and env files reside.

In order to make using the plugin easier to understand, I use that folder in the documents to specify a path to a user data folder. And I make the persistent data end up in the compose (appdata) folder next to the yml and env files. I decided to explain it that way because it seemed easier to understand.

It doesn't really matter, you can specify the path you want in that folder and use it for the type of data you want, or even not use it if you don't want and use absolute paths in compose files, symlinks or whatever you want.

We could talk for many hours about this because there are millions of possible configurations possible. If you have read the docs and understood how the plugin works, that was the goal, you should be able to use the plugin's tools to create your own configuration of folders, paths, hard drives, etc., and use the CHANGE_TO_COMPOSE_DATA_PATH variable for what you prefer.

The CHANGE_TO_COMPOSE_DATA_PATH was added to the plugin because the plugin's backup and restore didn't support environment variables in the paths of volumes. Now that it does support environment variables in the paths, it has less value other than making the example compose files easier. But as chente said, use what works for you. If it works and backs up, that is all that matters.

Zitat von notnormalnerd

the plugin and docs seem to contradict each other.

I have modified the text in this part of the wiki document. I think that will avoid confusion.

Zitat von notnormalnerd

There is an option to Clear Cache on my Prod server in the Settings for Compose. What exactly is that doing?

With the 7.2 release of the Compose plugin, each tab is cached to make them faster. The Clear Cache button clears the cache for all tabs so that they reload fresh info.