[Feature]: Built in Off-site Backup

[palitu]

trafficstars

Feature detail

I am just getting started with Immich, and i was thinking about the fact that we 'backup' our photos with it.

I think it would be fantastic if we could add another feature (which is almost invisible), that immich with automatically do backup into an offsite area, like backblaze B2 (S3 compatible storage).

I personally use Duplicati to enable my offsite backups, and i think this will give a full 3-copy type resilience, with almost no work on the user!

I would imagine you would just configure your end-point (stick simple with S3 or similar), and immich handles the rest. Then the user takes care of the cost of the offsite storage.

Cheers

Platform

Server

[alextran1502]

At first, I have the same idea of providing some kind of second layer backup to the user but the variety is too great so we didn't consider implementing it at all and leaving the offsite backup to the user.

If you have an idea, please collaborate further, I will take a look and talk to the team about the implementation.

Thanks

[MalteKiefer]

@palitu B2 would be greate so much cheaper then server storage

[bertmelis]

Another option would be to be able to put the server in maintenance mode and perform a backup with other tools (rclone, borg...). I'm a bit hesitant to do backups on running systems because DB and files could be out of sync or partial uploads or...

[danielyrovas]

yeah a shell script/cron job that switches off the containers and then borgs away the images should probably do the trick

[palitu]

My thought was to just bundle in, or to work with something like duplicati, that would perform offside backups. To begin with, I would be happy with storage of assets, not the entire setup.

I would even go so far as limiting the backup to S3 compatible only, or B2 only, and keep it very rudimentary. As it is, whilst I use this, I still keep my folder sync running to ensure that the files are copied, and backed up offsite every night.

[bo0tzz]

Proper incremental backup is a whole class of its own, and better served by specialized tools such as Duplicati. A script that shuts down the server and takes a backup should work pretty well with minimal fuss. In the future, if we manage to implement export functionality, you could also use that from a script to make backups with no downtime.

[bertmelis]

True, but instead of shutting down and starting up, I'd prefer to put Immich in "maintenance mode".

It is a mess to create a reliable script when using Podman because the backup user cannot access other users containers. Even for root itself it is clumsy.

[alextran1502]

You can perform a maintenance mode by temporarily shutting down the container. I think it is how most company perform maintenance on their services

[bertmelis]

Which one? Or the whole stack?

[bo0tzz]

server and microservices are currently the only containers that modify the filesystem/database, so at least those two. Probably the postgres container as well, if you want to be completely safe.

[driftywinds]

What about using b2 storage as the main form of storage for Immich instead of as a backup option? Will that be too hard to implement?

[alextran1502]

@driftywinds I would say all the features are possible to implement, but it comes down to priority and maintainability to integrate them into the application. We would rather do a good job of the core functionality and let third party tool such as Duplicati handle the offsite backup since they are known for that

[bo0tzz]

@driftywinds also see #1683