I wouldn't be surprised if there were some sysfs files that block until a certain event happens on some device. Which could be never. So yeah, an attempt to back that up wouldn't go anywhere :) You can run into similar issues if you use recursive grep on /.
Well it looks like GOG's forum just ate my post so let me try again..

I tried hdparm on my thinkpad's card reader, and as expected, it achieved nothing since the ioctl is not implemented by the mmcblk layer.

So I implemented it, and tada, write protect can be bypassed just like that, in software, by telling software to ignore the "protection" and write anyway. No hardware involved. See screenshot for proof.

now there's an example of a catalogue of confusions and misconceptions commonly induced by years of self-abuse by using certain computer software)

Well I'm not sure about this /proc thing but I don't see why a file would only be partially readable, or why it wouldn't be possible to back it up like nay other file (as I understand it, dd just copies everything byte-for-byte, doesn't it?), but it's possible that I may have understood something, and there was a lot to read so I'll admit I just skimmed some of it.

Because in Linux, Everything is a File (TM).
Which also means that not all files are files. :)

Some "files" are entry points to system stuff that you'd have to query APIs in C (or similar) to get at in Windows.

you don't usually try to "back up" some nether regions of deeply sensitive system part of windoze registry (and a handful of dll's from system32 along with it) and then cram it back into another windoze do you?
which to top it all off are created on the fly each time or even change at runtime...

anyway you're starting from the wrong end.
you're getting dangerously close to ioctls and stuff.
next thing they'll try to back that up as well in this thread.

Well I was just talking about a full disk copy and restore, to back up everything all at once. Sometimes that's the easiest thing to do, if you're just taking a precaution against a possible drive crash or something.

Actually, I'm slightly back to the drawing board. First of all, I'm very happy with Linux Mint running on my HD, but I also want to install on a USB stick, and I've been looking into doing that read-only to minimize (or entirely eliminate) wear and tear (there's no wear and tear from reading data, right?). In any case, the installation in question will have all system settings pre-configured before it's made read-only, and any saving will be onto other drives. It will be used for running one program, which doesn't auto-save any temp files. I'll have no swap partition or swap file, and I think I have a way to disable journaling (which I think is like logging, right?). So I wouldn't think there should be a problem.

So I asked a question about it on other message boards and as usual I got a run-around. But here people are actually helpful (and this isn't even a Linux-themed website, go figure). So I thought you might be able to advise me please.

Anyway, some people did say that I shouldn't/can't do that in Mint, and there are other distributions that are better at it (I think they're referring to "lightweight" ones such as Puppy and Porteus). I looked up Porteus and couldn't even figure out how to download it from any of the mirrors, because there's a list of files similar to GitHub, but no evident way to download all at once.

However, I also found this:

https://www.addictivetips.com/ubuntu-linux-tips/mount-file-systems-as-read-only-on-linux/

If you scroll down to where it says the heading "Permanently mount file systems as read-only" it explains how to do that, but I'll provide a summary here:

sudo cp /etc/fstab /etc/fstab.bak
sudo nano -w /etc/fstab
add the "ro" option at that line, for example:
UUID=96E4E375E4E35651 /media/data-storage-windows ntfs defaults,ro 0 2
press Ctrl-O to save and Ctrl-X to exit

So in other words, back up the fstab file, then edit it so that it says to make the drive read-only. But I wanted to verify, will this actually work for a Linux Mint OS drive, so that it won't write anything onto the drive as long as the fstab file is altered in that way, so that I could configure all settings until they're exactly how I want, then do this, and then everything will stay exactly the same, but I'd still be able to run a program from the USB drive and save data onto other drives such as a hard drive?

EDIT: Out of curiosity, I just looked in the fstab file on my HD and the line says something like:

UUID=[Blah Blah Blah] / ext4 errors=remount-ro 0 1

So in this case I can see it's mounted to / and it's ext4 instead of ntfs, but instead of defaults,ro it says errors=remount-ro. So this implies it already has the ro in it, but it doesn't say it after defaults, but rather after errors and specifying to remount. I'm only speculating but it seems to mean that if there's an error of some kind then it will attempt to remount the drive in a read-only way, but the syntax here is entirely different than what I was lead to expect. Also, the numbers are 0 1 rather than 0 2, but I don't know the significance of that.

Mount options are per-partition rather than per-drive, but yes, just make sure you do that for all partitions if there's more than one. It will work assuming the OS dosen't mess with your fstab. (I don't think they usually do, but you never know what they come up with). It will work in that changes to that partition are no longer possible, but of course this can break some software that expects to write shit. You'll probably find out if something important breaks. I don't know how dire the situation is now but I'd expect to find some programs that try to persist settings or cache things.. you can work around that by (bind) mounting tmpfs on the directory where they write, or perhaps making a symlink to tmpfs. You're right, it remounts read-only if there are errors. That field is a comma-separated list of mount options. errors=remount-ro is a mount option, as you can find in the man page of mount. As for the last two fields, the first one is used by dump (backup tool that nobody ever uses these days; 0 means don't dump) and the final one specifies the order in which the filesystems are checked when multiple are present. This is documented in the man page of fstab.

Do *you* have 128 terabytes on your machine? If not, there's no way that you could have enough space to actually store a file that large.

In the case of /proc/kcore, the file contains a dump of all of memory. Different parts of memory are mapped to different locations in memory, and those locations are reflected in the file, so if (for some reason) you're reading the file, you would need to read the area corresponding to the area of memory you need to look at.

On 64-bit CPUs, the address space is huge (I believe it's actually 128 terabytes on modern x86_64 CPUs, but could be increased if some day that's not enough RAM), and you most likely don't have enough physical memory to back all of it. Therefore, much of the file corresponds to areas of the address space that are not backed by physical memory, and therefore reading from the corresponding parts of /proc/kcore is not going to work.

(In case you're wondering, to my understanding this file exists to assist with debugging the kernel, but I don't know how one would actually use it. In any case, it does not exist on arm64 Linux.)

clarry, thanks for the explanations. I don't think I need to worry about any software trying to make any temp files, because I can take pretty much everything out of startup, and there's really only one program that will ever be used on this installation, which I know for a fact doesn't automatically write anything to any drive. I'm more worried about the OS trying to write anything, but if I disable swap, journaling, and so on, I wouldn't see why it would need to - I could be wrong though. I'm not sure what you mean by (bind) mounting tmpfs, because I'm not sure what a tmpf is and I don't know why a symlink would help, but from this context I guess you mean that I should mount something in such a way that I bind and thus restrict it from being written to, or am I misunderstanding that?

dtgreene, no I have like 2 TB, but my USB drives only use 8 GB, so I don't know why I would have a 128 TB file. To clarify, 64 bits should be able to address 16 exabytes, but I'm not sure any computer in the world has that much memory.

Yeah I guess there's one way to find out. tmpfs is a "filesystem" that never hits the disk, it's all in RAM, and you would normally find it mounted under /tmp. Now what if you find out that some application *really* wants to write something under ~/.config/?

You could mkdir /tmp/config, then mount -o bind /tmp/ /home/clarry/.config/ and now whatever file that application writes appears under /tmp/config/. Writes will succeed but it stays in RAM. The application will be happy. And all of it is gone when you power off or reboot. Bind mounts are a way to make one part of the directory hierarchy (in this case /tmp/config) appear at another place, in this case ~/.config/.

Sometimes you can achieve the same result by making ~/.config/ a symlink that points to /tmp/config/. However, symlinks aren't completely transparent and in some rare cases you can't fool an application with them.

Well that's all interesting; I'll keep that in mind, but does that mean I have to find each program that references one path and change it to another path, or by mounting in that way it will fool nearly all programs into thinking saving only into RAM?

Also, what about modifying fstab to make the drive read only - would that work? Or how about a chmod to set permissions on / and do it recursively to all directories and all files?

User applications would write their junk somewhere under your home directory, so if you put that on a tmpfs, that should fool them all. Some system software likes to store junk under /var. Logs, cache, etcetra. Obviously that prevents writing but I wouldn't be surprised if some application out there just crashes if it can't write what it wants to. Or spews lots of error messages or similar. Same problem as above.

Doing this will remove the setuid bit from binaries, which will result in programs like sudo no longer working.

Also, removing the executable bit will make it impossible to run user-space programs. The first symptom is that you won't be able to start any programs. The second symptom is that, if you reboot, the system will fail to boot.

In other words, don't do this; *never* do a recursive chmod on /.

(It is not easy to recover from this without doing a full re-install of the OS.)

On my system: This is on a system with "only" 16 GB RAM, 128 GB SSD, and 2 TB hard drive (and a 4 TB USB drive that isn't connected).

Also, according to Wikipedia, current x86_64 processors only use 48 of the bits in the address, resulting in the address space being "only" around 256 TB.

Ahhh. Now that is my kind of paranoia. :D

Friendly advice: You're not at the level of computer mastery that you want to roll your own backup solution.
Use existing, dedicated tools for that task. You'll save yourself no end of grief.

Anyhu, I'd say that full disc backups are hardly the most convenient for most use cases.
Wouldn't it make much more sense to just back up your data and settings?