.. _backup:

Backup and Restore
===================

Backup
-------

.. warning::

  Out of the box, CoCalc OnPrem does not provide you with any backups.
  You have to do this yourself.

.. note::

  There is a feature called `TimeTravel <https://doc.cocalc.com/time-travel.html>`_, which records all changes to editable files and allows users to restore them. However, this is not a "real" backup, because all such changes are stored in the database.


There are three aspects to take care of:

1. Backup of your :ref:`my-values.yaml <my-values.yaml>` file. If you store this in a :term:`Git` repository, push it to a private respository.
2. :ref:`database`: there are many ways how to backup a :term:`PostgreSQL` database.

   - PostgreSQL Guide: `Backup and Restore <https://www.postgresql.org/docs/current/backup.html>`_.
   - A solid way is `pgBackRest <https://pgbackrest.org/>`_.
   - If you use a HELM chart to deploy it, there might already be support for backups.
   - Managed SQL services in public clouds do provide backups for you as well, e.g. :ref:`GCP SQL Backup <gke-database>`.

3. :ref:`storage`: this is a filesystem shared across all projects and some services. You have to backup the underlying disk holding all the data. A modern and robust way is to make period :term:`Snapshots <Snapshot>`. Managed clouds provide snapshots, e.g. :ref:`GCP Disk Backup <gke-disk-backup>`.

Restore
--------

If you have the above, you should be able to restore everything.

1. **my-values.yaml**: get your :ref:`previous my-values.yaml <my-values.yaml>` file.
2. **Database**: restore it from a backup. Check that you can sign in using the configured host and user, and that the stored :term:`Secret` in :term:`Kubernetes` still works as well. Use the :ref:`db-shell.sh <troubleshooting-database>` script – or something similar – to be sure you can access the restored database from within the namespace in your cluster.
3. **Files**: this depends on how your type of storage, how it was setup, etc. Basically, there are two :term:`PersistentVolumeClaim`, which will be used by the deployments – see :ref:`projects-data`. If they were create automatically and no longer match with the old ones, you have to copy over the file from the old location to the new location. This should be really easy, though:

   - The PVC for projects has to subdirectories: ``projects`` and ``shared``. The ``projects`` subdirectory has a directory for each project named after its ID. That's essentially the data your users are most interested in. The ``shared`` directory contains published files, essentially a copy of files in specific projects.
   - The other PVC is for the ``/ext`` shared directory. It contains :ref:`global software and data <projects-software>`.

.. note::

    As mentioned in :ref:`Architecture/Storage <architecture-storage>`, the UID must be 2001.
    Hence it might be necessary to run ``chown -R 2001:2001`` on all the restored files.