this post was submitted on 26 Oct 2023
1 points (100.0% liked)

Self-Hosted Main

515 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
communick@selfhosted.forum
1
Migrating from ARM to X86 (alien.top)
submitted 1 year ago by SnowyLocksmith@alien.top to c/main@selfhosted.forum
13 comments fedilink hide all child comments
 

Hello All,

I currently have a home server on a raspberry pi 4 with all my services running as docker containers. All containers have their own directories containing the config and database files. This makes it easy to backup and export then.

​

However, in the future I have plans to migrate to a more powerful server. This means I will probably not be using a CPU with an ARM architecture. So effectively, I will also have to use the corresponding docker images. So will this new x86 docker image work with my backup docker config volumes?

you are viewing a single comment's thread
view the rest of the comments
[–] -myxal@alien.top 2 points 1 year ago (1 children)

So then, since the config data is mounted as a volume, should its format be decided by the linux image, i.e. it should be more or less standard, right?

The volume mechanism in docker is nothing more than a means of allowing a part of the container's filesystem to be redirected to a directory on the host OS - not that dissimilar from networked file-sharing. It has no bearing on what's in the saved files.

The format of the config/data is determined by the app developer. The app developer makes a choice in how the config/data is written from the app's memory to a file on a disk. If they write their data through libraries, using formats that are designed for CPU portability (Unicode text, sqlite DB, zip archive, etc.) then the data will be usable in the same app running under different CPU arch. But if they use non-portable formats, roll their own format, or just serialise objects from memory, those typically won't open/de-serialise correctly without extra effort on developer's part.

In practice IMHO it's down to what kind of apps you're using. Most stuff that's developed in the last 10 years or so, and not high-performance/custom code would default to using CPUarch-portable formats.

[–] SnowyLocksmith@alien.top 2 points 1 year ago

Thanks a lot for the detailed explanation