Cloudron Forum

Restic: https://restic.net
Supported repos out of the box: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
Other repos when combining restic with rclone: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#other-services-via-rclone

A starting point: https://docs.cloudron.io/guides/community/restic-rclone/

@ekevu123 Previously, we used something called "CPU Shares" (--cpu-shares in docker) . This option was a bit hard to understand since it comes to picture only when there is CPU contention between various apps (i.e when a server is overloaded to start with). We removed this and replaced it with an easier to explain "CPU Limit" (--cpu-quota in docker). This corresponds to how many cycles your app should be given. Like, you can say, give only 2 cores max to this app (in any situation). By default, apps have access to all your CPUs.

However, isn't the point that the default should be less than that so that one app cannot take down the whole server?

We couldn't think of a good default. Otherwise, apps will start out "crippled" and we thought it's better this way. I think if you have apps that are causing problems, only then should you look into tweaking this. This would be a stop gap measure before you try to report the issue and get the app fixed...

Ah, just found it - apparently, I restrict access to the page in the general settings, and then in the settings of the individual post, I can set access to "public". Then the page itself is still password-protected, but the text is now included into the API call.

@skeats Do you use it with Nextcloud? (missed the file server mention) Did you ever get any failed backup errors in CR dash?

@girish said in Backup time considers timezones incorrectly:

I think you are suggesting showing the Settings Timezone in the Backup Schedule UI, correct? If so, that's a good idea!

Yes, that was what I was suggesting

The timezone shown in the UI is based on browser timezone . If you had multiple admins, each in their timezones, then the UI shows the correct timestamps.

I understand the logic, however, have a look at the screenshot. screenshot-backup-time.png

Seemingly, the backup starts at 1am, but it finishes before 1am, which is confusing. In fact, it took 24 minutes in this case, but I am in a different time zone now, 1 hour back.

Maybe a temporary issue with your private docker registry or otherwise. Lets see if next time we have more info to work with.

@nevo-david Great work! And great to see you here!

Don't forget to post plenty of screenshots to help people here understand and upvote for your app.

I solved the port issue as well.
The problem occured when I tried to start an interactive shell, which counted as starting a second application inside the cloudron app, that's where the port conflict came from.

If someone else is working with Elixir on Cloudron, you can start an interactive shell like this:
/app/_build/prod/rel/APP/bin/APP remote

@ekevu123 the manifest error here refers to the docker image manifest. That part of the error message is from your upstream docker registry and not generated by cloudron.

I misread your original comment. I guess you are referring to the cloudron update command of the CLI tool. I thought this was about a cloudron (platform) update.

Currently, the focus of the CLI tool is app development and not for end users as such.... So, one can automate what you want already by writing a small script which calls cloudron restore if the update fails.

No, it was a one-time issue so far. I posted it more as a bug report.

Version 7.7.2, by the way.

@ekevu123 The template is a new idea. I have marked your original posted as edited by mod.

I looked into this further and have seen that Postmark provides the opportunity to avoid storing the body in their logs. I think that is reasonably safe. And since I already have a business account with them, I am going to attach my private e-mail account there as well.

Thank you for your assistance in this matter!

Thank you for the detailed response! Since this app doesn't run the LLM itself, the system requirements are less heavy.

But wouldn't everything that wasn't attached to Cloudron just run inside the container? I mean, let's say I write a dockerfile for this app, but "forget" to use the postgres addon of cloudron. Wouldn't the app still run, but with the database inside the app, so it would be overwritten upon updating?

Other than that, this app seems to have a sandbox container and one for vector databases, which couldn't be rebuilt easily in Cloudron.

For folks who need to self host this app, I created a comprehensive tutorial.

Create a fresh server, update and upgrade the system, install docker and docker compose with this one command.

sudo apt-get update -y &&
sudo apt-get upgrade -y &&
sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common gnupg lsb-release &&
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg &&
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null &&
sudo apt-get update -y &&
sudo apt-get install -y docker-ce &&
sudo usermod -aG docker $USER &&
sudo curl -L https://github.com/docker/compose/releases/download/v2.26.1/docker-compose-uname -s-uname -m -o /usr/local/bin/docker-compose &&
sudo chmod +x /usr/local/bin/docker-compose && \

Clone the Repo

git clone https://github.com/langgenius/dify.git

Customize the .env file

cd dify/docker
cp .env.example .env

I only customized the following variables.
APP_WEB_URL=your_domain_name
NGINX_HTTPS_ENABLED=true
NGINX_SSL_CERT_FILENAME=cert.pem
NGINX_SSL_CERT_KEY_FILENAME=key.pem

Ctrl S to save, Ctrl X to exit the nano editor.
cd -

Create SSL Certificate

Create ssl certificate at Cloudflare (open SSL/TSL tab and open Original Server)

nano dify/docker/nginx/ssl/cert.pem
Copy and paste the Cloudflare certificate, then Ctrl S, Ctrl X

nano dify/docker/nginx/ssl/key.pem
Copy and paste the Cloudflare SSL key, then Ctrl S, Ctrl X

Deploy

cd dify/docker
docker compose up -d

Upgrade

cd dify/docker
docker compose down
git pull origin main
docker compose pull
docker compose up -d

Setting Up Automated Backups for Dify Using Restic and Cloudflare R2 Step 1: Install Restic Connect to your server via SSH. Update your package list and install Restic:sudo apt update sudo apt install restic Step 2: Prepare Your Cloudflare R2 Bucket Create a new R2 bucket in your Cloudflare account if you haven't already. Note down the following information from your Cloudflare R2 setup: Bucket name Access Key ID Secret Access Key R2 Endpoint URL Step 3: Create the Backup Script

Create a new directory for the Restic script:

mkdir -p /root/restic

Create and open the backup script using nano:

nano /root/restic/backup.sh

Copy and paste the following content into the file:

#!/bin/bash # Set environment variables for Restic export RESTIC_REPOSITORY="s3:YOUR_R2_ENDPOINT_URL/YOUR_BUCKET_NAME" export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY_ID" export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_ACCESS_KEY" # Set the backup source BACKUP_SOURCE="/root/dify/docker/volumes" # Perform the backup restic backup $BACKUP_SOURCE # Prune old snapshots (keep last 7 daily, last 4 weekly, and last 12 monthly backups) restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune # Check the repository for errors restic check

Replace the following placeholders with your actual Cloudflare R2 information:

YOUR_R2_ENDPOINT_URL: Your Cloudflare R2 endpoint URL YOUR_BUCKET_NAME: Your R2 bucket name YOUR_ACCESS_KEY_ID: Your R2 Access Key ID YOUR_SECRET_ACCESS_KEY: Your R2 Secret Access Key

Save the file and exit nano:

Press Ctrl + X When prompted to save, press Y Press Enter to confirm the file name

Make the script executable:

chmod +x /root/restic/backup.sh

Secure the script (as it contains sensitive information):

chmod 700 /root/restic/backup.sh Step 4: Initialize the Restic Repository

Set the environment variables (replace with your actual R2 information):

export RESTIC_REPOSITORY="s3:YOUR_R2_ENDPOINT_URL/YOUR_BUCKET_NAME" export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY_ID" export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_ACCESS_KEY"

Initialize the Restic repository:

restic init Step 5: Set Up Daily Backups

Open the crontab file:

crontab -e

If prompted to select an editor, choose nano by entering the corresponding number.

Add the following line at the end of the file to run the backup daily at 3 AM:

0 3 * * * /root/restic/backup.sh > /root/restic/backup.log 2>&1

Save the file and exit nano:

Press Ctrl + X When prompted to save, press Y Press Enter to confirm Verifying the Setup

To ensure everything is set up correctly:

Run the backup script manually:

/root/restic/backup.sh

Check the Restic repository for snapshots:

restic snapshots Restoring from a Backup

To restore your data:

List available snapshots:

restic snapshots

Restore the latest snapshot:

restic restore latest --target /path/to/restore

Replace /path/to/restore with the directory where you want to restore the data.

Done.

@timbo I have practically zero spam with the rules mentioned in my post and abusix DSNBL (https://abusix.com/) - the free tier is sufficient.
Do you have catch-all enabled?

Thank you! Yeah, I'll stick with 777 in this context.