Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: Disaster Recovery #427

Open
scott-grimes opened this issue Mar 7, 2023 · 3 comments
Open

Documentation: Disaster Recovery #427

scott-grimes opened this issue Mar 7, 2023 · 3 comments

Comments

@scott-grimes
Copy link

My org is evaluating openwisp as a potential solution for our mesh. I've not been able to find any documentation about backup and restore / disaster recovery.

I'm happy to write a PR to add a pointer to this document if it exists, and/or edit the readme in the docs repo to include a section on this if someone can point out what it would exactly entail

I'm assuming backups would entail:

  1. taking database snapshot (/opt/openwisp2/db.sqlite3 or your externally-defined database)
  2. ditto for influxdb if you have metrics being stored

Some questions:

  1. what else would be needed to fully restore an instance of openwisp?
  2. are any files written to disk?
  3. what would restore procedure look like?
@nemesifier
Copy link
Member

nemesifier commented Mar 7, 2023

Hi @scott-grimes and welcome!
Here's the info you're looking for, I hope this helps.

  1. taking database snapshot (/opt/openwisp2/db.sqlite3 or your externally-defined database)

Yes or if you use another DB (eg: PostgreSQL) use the dump tool of the DB to get the SQL dump.

  1. ditto for influxdb if you have metrics being stored

Depends on you, consult influxdb docs for that.

Some questions:

  1. what else would be needed to fully restore an instance of openwisp?

Anything in /opt/openwisp2, especially /opt/openwisp2/private, /opt/openwisp2/media.

  1. are any files written to disk?

Yes, user uploaded files (firmware images, floorplans, etc, in the directories mentioned above).

  1. what would restore procedure look like?

Restore files, restore DB, restore influxdb metrics with the influxdb restore tool if needed and wanted, start the application (eg: supervisorctl start all).

@scott-grimes
Copy link
Author

Thanks @nemesisdesign ! Done a bunch of tests for this over the last week. I'm using an external database, no influxdb for now.

I currently don't have anything in the folders /opt/openwisp2/private or /opt/openwisp2/media on the test instance I'm working with, I'm presuming that would be images/uploads like you said that get stored there.

I've done a tear-down and rebuild a few times now successfully.

Starting with a fresh vm I

  1. Load the database with the backup
  2. Execute the playbook.

Openwisp seems to start up just fine from this. The nginx config, etc all get rebuilt according to the playbook.yml and vars that are set there.

I noticed in https://github.com/openwisp/docker-openwisp that only the following two paths are persisted for the openwisp container

volumeMounts:
  - name: openwisp-static-data
     mountPath: /opt/openwisp/static
  - name: openwisp-media-data
     mountPath: /opt/openwisp/media

Would backing up just those two directories (plus the database) suffice to rebuild an instance from scratch? Is there a reason that the private directory is excluded in the dockerized version, or is that just an oversight considering that it is in alpha?

@nemesifier
Copy link
Member

Would backing up just those two directories (plus the database) suffice to rebuild an instance from scratch? Is there a reason that the private directory is excluded in the dockerized version, or is that just an oversight considering that it is in alpha?

It's simply docker-openwisp not keeping up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants