Linux

48674 readers

375 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago

MODERATORS

[email protected]

What is your partitioning strategy to achieve a stable, backup-able and recoverable system? (lemm.ee)

submitted 1 year ago by [email protected] to c/[email protected]

41 comments fedilink hide all child comments

Hello, I've been a long time Linux user but I had a 5 years break and I am coming back to it now.

I've been trying several Linux distributions in the past week, installing the packages and configuring them as I need with several different orders of success.

My last case was an Ubuntu installation that I was very happy with and pretty close to call it setup and done, until I installed virtualbox and restarted the system only to find it bricked.

Obviously I could try to drop into one of the terminals on ctrl + alt + Fx and fix it, but I wonder if I could be smarter about it and be more prepared for this kind of situation.

One of the starting points I think would be having a separate home partition from the rest of the system. I used to have it in the past and it was great.

But then what's next? What are the best FS I could pick for each type of partition? A performant one to keep the code and package manager cache, a journaling/snapshop based one for system, another type for game data, etc etc.

What if I would like to have a snapshot of working version of my system backed up somewhere ready to restore as simple as simple as possible?

How do you configure your systems in order to quickly recover from an unexpected bricking without growing some more white hairs, and squeezing as much performance vs feature for each of your use case?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

My strategy has always been to separate what should be persistent from what shouldn't be.

On every system I deploy for home or work, I have a tree similar to below

/storage/[local/remote]/[where it is, enclosure, backplane,etc]/[what it is]

E.g

/storage/local/e1/raid/r6a/[this is my mount point] /storage/remote/nfs4/oldserver/[this is my mount point]

I then build all of my workflows off of the assumptions that things go there. Docker containers have a subdirectory in r6a for persistent volumes, etc

Even my containers themselves have a /storage/remote/persistent that I symlink anything to that I care about.

On the desktop side, I tend to physically just mount a second drive or a second partition as a subdirectory of /storage. That way my assumption can always be safe in that if it's a subdirectory of a mount, my data is safe. If it's not, it isn't. It's also nonstandard, so I can be relatively certain I won't have conflicts between different distributions.

The main issue I have with submounting system directories like /home is that applications tend to put junk there, and old junk might not be compatible with a newer version of, or different distro. It can make for more effort than it's worth