immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 13 Packages Projects Releases 10 Wiki Activity

[Feature]: Built in Off-site Backup #180

New Issue
Closed
opened 2026-02-04 18:27:31 +03:00 by OVERLORD · 13 comments
OVERLORD commented 2026-02-04 18:27:31 +03:00
Owner
Copy Link

Originally created by @palitu on GitHub (Aug 1, 2022).

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

Originally created by @palitu on GitHub (Aug 1, 2022). ### 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
OVERLORD commented 2026-02-04 18:27:44 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 1, 2022):

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

@alextran1502 commented on GitHub (Aug 1, 2022): 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
OVERLORD commented 2026-02-04 18:27:56 +03:00
Author
Owner
Copy Link

@MalteKiefer commented on GitHub (Aug 1, 2022):

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

@MalteKiefer commented on GitHub (Aug 1, 2022): @palitu B2 would be greate so much cheaper then server storage
OVERLORD commented 2026-02-04 18:28:09 +03:00
Author
Owner
Copy Link

@bertmelis commented on GitHub (Aug 1, 2022):

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...

@bertmelis commented on GitHub (Aug 1, 2022): 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...
OVERLORD commented 2026-02-04 18:28:15 +03:00
Author
Owner
Copy Link

@danielyrovas commented on GitHub (Aug 3, 2022):

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

@danielyrovas commented on GitHub (Aug 3, 2022): yeah a shell script/cron job that switches off the containers and then borgs away the images should probably do the trick
OVERLORD commented 2026-02-04 18:28:25 +03:00
Author
Owner
Copy Link

@palitu commented on GitHub (Aug 14, 2022):

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.

@palitu commented on GitHub (Aug 14, 2022): 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.
OVERLORD commented 2026-02-04 18:28:26 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Oct 21, 2022):

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.

@bo0tzz commented on GitHub (Oct 21, 2022): 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.
OVERLORD commented 2026-02-04 18:28:35 +03:00
Author
Owner
Copy Link

@bertmelis commented on GitHub (Oct 21, 2022):

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.

@bertmelis commented on GitHub (Oct 21, 2022): 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.
OVERLORD commented 2026-02-04 18:28:46 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Oct 21, 2022):

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

@alextran1502 commented on GitHub (Oct 21, 2022): You can perform a maintenance mode by temporarily shutting down the container. I think it is how most company perform maintenance on their services
OVERLORD commented 2026-02-04 18:28:50 +03:00
Author
Owner
Copy Link

@bertmelis commented on GitHub (Oct 21, 2022):

Which one? Or the whole stack?

@bertmelis commented on GitHub (Oct 21, 2022): Which one? Or the whole stack?
OVERLORD commented 2026-02-04 18:28:58 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Oct 21, 2022):

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.

@bo0tzz commented on GitHub (Oct 21, 2022): `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.
OVERLORD commented 2026-02-04 18:29:08 +03:00
Author
Owner
Copy Link

@driftywinds commented on GitHub (Aug 25, 2023):

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?

@driftywinds commented on GitHub (Aug 25, 2023): 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?
OVERLORD commented 2026-02-04 18:29:15 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Aug 25, 2023):

@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

@alextran1502 commented on GitHub (Aug 25, 2023): @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
OVERLORD commented 2026-02-04 18:29:20 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Aug 25, 2023):

@driftywinds also see #1683

@bo0tzz commented on GitHub (Aug 25, 2023): @driftywinds also see #1683
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#180
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?