# Longhorn distributed block storage system

## For users

You should really avoid using Longhorn as it has over time proven to be
unreliable system. Prefer using remote databases in your application via
the Kubernetes operator pattern.

Use Longhorn for applications that need persistent storage, but are unable
to provide replication in the application layer:

* Applications that insist writing into filesystem
* Applications that serve Git repositories (eg Gitea)
* Applications that check out Git repositories (eg Woodpecker, Drone and CI systems)
* Applications that need to use SQLite

Instead of using built-in `longhorn` storage class, please add new storage class
with suitable replication, data locality parameters and reclaim policy
[here](https://git.k-space.ee/k-space/kube/src/branch/master/storage-class.yaml)

Longhorn backups are made once per day and it's configured to be uploaded to
the Minio S3 bucket hosted at nas.k-space.ee


## For administrators

Longhorn was last upgraded with following snippet:

```
wget https://raw.githubusercontent.com/longhorn/longhorn/v1.6.2/deploy/longhorn.yaml
patch -p0 < changes.diff
kubectl -n longhorn-system apply -f longhorn.yml -f application-extras.yml -f backup.yaml
```

After initial deployment `dedicated=storage:NoSchedule` was specified
for `Kubernetes Taint Toleration` under `Setting -> General` on
[Longhorn Dashboard](https://longhorn.k-space.ee/).
Suitable nodes were tagged with  `storage` and Longhorn scheduling was disabled on others.

Refer to `application.yaml` to see how backups are configured.