2016-02-11 12:25:00 +00:00
|
|
|
.. _migrating:
|
|
|
|
|
|
|
|
|
|
Migrating, Updates, and Backups
|
|
|
|
|
===============================
|
|
|
|
|
|
|
|
|
|
As *Paperless* is still under active development, there's a lot that can change
|
2016-03-03 20:52:42 +00:00
|
|
|
as software updates roll out. You should backup often, so if anything goes
|
|
|
|
|
wrong during an update, you at least have a means of restoring to something
|
|
|
|
|
usable. Thankfully, there are automated ways of backing up, restoring, and
|
|
|
|
|
updating the software.
|
Add Dockerfile for application and documentation
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
2016-02-17 18:45:04 +01:00
|
|
|
|
2016-02-11 12:25:00 +00:00
|
|
|
|
|
|
|
|
.. _migrating-backup:
|
|
|
|
|
|
|
|
|
|
Backing Up
|
|
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
So you're bored of this whole project, or you want to make a remote backup of
|
|
|
|
|
the unencrypted files for whatever reason. This is easy to do, simply use the
|
2016-03-03 20:52:42 +00:00
|
|
|
:ref:`exporter <utilities-exporter>` to dump your documents and database out
|
|
|
|
|
into an arbitrary directory.
|
Add Dockerfile for application and documentation
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
2016-02-17 18:45:04 +01:00
|
|
|
|
2016-02-11 12:25:00 +00:00
|
|
|
|
|
|
|
|
.. _migrating-restoring:
|
|
|
|
|
|
|
|
|
|
Restoring
|
|
|
|
|
---------
|
|
|
|
|
|
|
|
|
|
Restoring your data is just as easy, since nearly all of your data exists either
|
|
|
|
|
in the file names, or in the contents of the files themselves. You just need to
|
|
|
|
|
create an empty database (just follow the
|
|
|
|
|
:ref:`installation instructions <setup-installation>` again) and then import the
|
|
|
|
|
``tags.json`` file you created as part of your backup. Lastly, copy your
|
|
|
|
|
exported documents into the consumption directory and start up the consumer.
|
|
|
|
|
|
2016-03-03 20:52:42 +00:00
|
|
|
.. code-block:: shell-session
|
2016-02-11 12:25:00 +00:00
|
|
|
|
|
|
|
|
$ cd /path/to/project
|
|
|
|
|
$ rm data/db.sqlite3 # Delete the database
|
|
|
|
|
$ cd src
|
|
|
|
|
$ ./manage.py migrate # Create the database
|
|
|
|
|
$ ./manage.py createsuperuser
|
|
|
|
|
$ ./manage.py loaddata /path/to/arbitrary/place/tags.json
|
|
|
|
|
$ cp /path/to/exported/docs/* /path/to/consumption/dir/
|
|
|
|
|
$ ./manage.py document_consumer
|
|
|
|
|
|
Add Dockerfile for application and documentation
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
2016-02-17 18:45:04 +01:00
|
|
|
Importing your data if you are :ref:`using Docker <setup-installation-docker>`
|
|
|
|
|
is almost as simple:
|
|
|
|
|
|
|
|
|
|
.. code-block:: shell-session
|
|
|
|
|
|
2016-03-03 20:52:42 +00:00
|
|
|
# Stop and remove your current containers
|
Add Dockerfile for application and documentation
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
2016-02-17 18:45:04 +01:00
|
|
|
$ docker-compose stop
|
|
|
|
|
$ docker-compose rm -f
|
|
|
|
|
|
2016-03-03 20:52:42 +00:00
|
|
|
# Recreate them, add the superuser
|
Add Dockerfile for application and documentation
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
2016-02-17 18:45:04 +01:00
|
|
|
$ docker-compose up -d
|
|
|
|
|
$ docker-compose run --rm webserver createsuperuser
|
|
|
|
|
|
2016-03-03 20:52:42 +00:00
|
|
|
# Load the tags
|
Add Dockerfile for application and documentation
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
2016-02-17 18:45:04 +01:00
|
|
|
$ cat /path/to/arbitrary/place/tags.json | docker-compose run --rm webserver loaddata_stdin -
|
|
|
|
|
|
2016-03-03 20:52:42 +00:00
|
|
|
# Load your exported documents into the consumption directory
|
|
|
|
|
# (How you do this highly depends on how you have set this up)
|
Add Dockerfile for application and documentation
This commit adds a `Dockerfile` to the root of the project, accompanied
by a `docker-compose.yml.example` for simplified deployment. The
`Dockerfile` is agnostic to whether it will be the webserver, the
consumer, or if it is run for a one-off command (i.e. creation of a
superuser, migration of the database, document export, ...).
The containers entrypoint is the `scripts/docker-entrypoint.sh` script.
This script verifies that the required permissions are set, remaps the
default users and/or groups id if required and installs additional
languages if the user wishes to.
After initialization, it analyzes the command the user supplied:
- If the command starts with a slash, it is expected that the user
wants to execute a binary file and the command will be executed
without further intervention. (Using `exec` to effectively replace
the started shell-script and not have any reaping-issues.)
- If the command does not start with a slash, the command will be
passed directly to the `manage.py` script without further
modification. (Again using `exec`.)
The default command is set to `--help`.
If the user wants to execute a command that is not meant for `manage.py`
but doesn't start with a slash, the Docker `--entrypoint` parameter can
be used to circumvent the mechanics of `docker-entrypoint.sh`.
Further information can be found in `docs/setup.rst` and in
`docs/migrating.rst`.
For additional convenience, a `Dockerfile` has been added to the `docs/`
directory which allows for easy building and serving of the
documentation. This is documented in `docs/requirements.rst`.
2016-02-17 18:45:04 +01:00
|
|
|
$ cp /path/to/exported/docs/* /path/to/mounted/consumption/dir/
|
|
|
|
|
|
|
|
|
|
After loading the documents into the consumption directory the consumer will
|
|
|
|
|
immediately start consuming the documents.
|
2016-03-03 20:52:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
.. _migrating-updates:
|
|
|
|
|
|
|
|
|
|
Updates
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
For the most part, all you have to do to update *Paperless* is run ``git pull``
|
|
|
|
|
on the directory containing the project files, and then use Django's ``migrate``
|
|
|
|
|
command to execute any database schema updates that might have been rolled in
|
|
|
|
|
as part of the update:
|
|
|
|
|
|
|
|
|
|
.. code-block:: shell-session
|
|
|
|
|
|
|
|
|
|
$ cd /path/to/project
|
|
|
|
|
$ git pull
|
|
|
|
|
$ cd src
|
|
|
|
|
$ ./manage.py migrate
|
|
|
|
|
|
|
|
|
|
Note that it's possible (even likely) that while ``git pull`` may update some
|
|
|
|
|
files, the ``migrate`` step may not update anything. This is totally normal.
|
|
|
|
|
|
|
|
|
|
If you are :ref:`using Docker <setup-installation-docker>` the update process
|
|
|
|
|
requires only one additional step:
|
|
|
|
|
|
|
|
|
|
.. code-block:: shell-session
|
|
|
|
|
|
|
|
|
|
$ cd /path/to/project
|
|
|
|
|
$ git pull
|
|
|
|
|
$ docker build -t paperless .
|
|
|
|
|
$ docker-compose up -d
|
|
|
|
|
$ docker-compose run --rm webserver migrate
|
|
|
|
|
|
|
|
|
|
If ``git pull`` doesn't report any changes, there is no need to continue with
|
|
|
|
|
the remaining steps.
|