Persistence is covered reasonably well elsewhere in the wiki. However I think there are users using “persistent /home” when they don't really need it. Please note that I do not mean to imply that “no one needs a persistent /home”. I can easily imagine use cases that -would- call for a persistent /home but it is worth thinking about it before deciding either way. My preference is to not have a persistent /home, though I do have plenty of persistent storage.

You probably will want to have your tce directory on persistent media. Pure cloud mode has its uses, but I wouldn't want to re-download all my apps every time I rebooted.

Once you have a persistent tce directory, that is the logical (and default) place for your backup file, mydata.tgz.

Without a persistent /home, all your personal settings and data files reside only in RAM so anything that is not in your backup -will be gone- after a reboot.

Your backup is managed by editing /opt/.filetool.lst to include files or directories and by editing /opt/.xfiletool.lst to exclude certain files that would otherwise be included. Both of these files are pre-populated with reasonable default lists, but they will need to be maintained.

But what do you do when your backup starts getting so big that it takes a noticeable amount of time to make it during shutdown and to restore the data during bootup? You revisit your data storage policy, that's what.

do you have a bunch of photos or mp3 files in your home directory?

do you have email from your cousin where the subject line starts with “FW: Fw: FW: Fwd:…” and includes an attached image that's mildly funny but you've seen it before? And the image is attached once -for each time it was forwarded-!?

are you using one of the firefoxes?

what else is in your backup?

I have always kept my mp3 collection and family photo collection on persistent media. They're huge and they're static (and they predate Tiny Core). No need to keep them in my home directory.

I've become very reluctant to keep emails around for long - especially those with attachments of any kind.

/opt/.xfiletool.lst excludes firefox's cache directory by default, but how about all those sqlite files that I have no idea what's in them? I hate data files that I can't read in a text editor, and these things seem to grow. Here's a solution:

tar up the entire (new) ~/.mozilla directory and stash the .tgz file in the tce directory.

add a line to the end of /opt/bootsync.sh to un-tar the tgz file back to the home directory.

edit /opt/.xfiletool.lst to exclude .mozilla from the backup.

NOTE: no new bookmarks will be persistent across reboots, so any bookmarks that are to saved should also be saved to a file in ~/ then periodically, maybe weekly or monthly, recreate the tar file after adding the new bookmarks from the save file - but only do this immediately after a reboot so as to maintain the clean state of the browser.

And, for the final touch, create a directory on the file system where the tce directory resides to hold any static files that you want to keep handy but which don't need to be backed up again and again. I call mine homestatic. Move those miscellaneous sound, image and pdf files out of ~ and out of your backup file.

In addition to cleaning up your backup, the above steps should start you thinking about “data retention policy” - what do you really need, or even want, to keep around.

I don't know how much backup/restore time the browser trick saved me, since that data still gets restored on every reboot, but at least the data set doesn't keep growing. And it solves the privacy/tracking-cookie issue. I do know that with all of the above, I was able to reduce my backup time from “almost a minute” to about seven seconds.

Once the partitioning and bootloader are out of the way, the “installation” of Core is an incredibly simple matter.

core 4.2.1 is installed in boot/core4.2.1/ as vmlinuz and core.gz. That was easy. I also include the 64 bit versions, even though I never use them, and the .md5.txt for all files and, just for good measure, I also grab words.db and provides.db, even though I never use them either (yet).

boot/core4.2.1/ also contains three subdirectories:

boot/cor4.2.1/core_elements/ contains the six extensions for the basic gui - Xlibs.tcz, Xprogs.tcz, fltk-1.10.tcz, Xvesa.tcz, wbar.tcz and jwm.tcz - along with their .info, .list, dep, .tree and .md5.txt files. These get copied to the tce directory.

boot/core4.2.1/iso/ contains the ISO files and their .md5.txt files and the f2, f3 and f4 files, which I extract from the ISOs

boot/core4.2.1/tce is the working tce directory. Keeping the tce directory under the version-specific directory makes it easy to keep a separate set of extensions when upgrading core.

I don't spend a lot of (any) time updating my extensions between OS updates unless something breaks, but each time I update the OS, I download a fresh copy of the extensions I use by simply looping through the old version's …tce/optional/*.tcz and “tce-load -w” each one (and then wget the .list, .info etc files). Yes there's the possibility of something breaking, but I'll deal with that if it happens. I keep the old version around for a while, just in case.

The tce/ directory also includes
local/ where I keep some personal extensions that get loaded manually… gtm5.tce - yeah, its still a .tce file. and the .tgz file of ~/.mozilla/

and
bin/ where I keep some scripts (like the one to load an old style .tce file …)

The root of the ext2 filesystem also contains two additional directories:
homestatic/ where I dump large static stuff that I don't want in mydata.tgz
tmp/ where I write a log of what happens, or fails to happen, from bootsync.sh on.