Created a dual boot about a year ago, and didn’t dare encrypt at install in case I mess something up.
But now it feels weird to have it unencrypted the times I decide to boot with Windows.
Is there a way to encrypt it post installation? Is it recommended to not do that?
Follow up if it’s not recommended: Is it better to do a total re-install, and in that case, is there some easy way to backup the current install and get it exactly as it is now - that is, not just the home folder, but everything.
Microsoft Windows cannot read any Linux-native filesystems. All it knows is NTFS and the various FAT derivatives.
Negative. However, considering that you’re using Plasma, Plasma has something called plasma-vault — it’s in the repositories — which allows you to create encrypted folders inside your home directory. You could put the more sensitive stuff in there.
You could make a timeshift backup — the rsync type, with physical copies, not the btrfs snapshot kind.
Before all else, it is important that you know how to handle a (fully) encrypted system in the case of problems - be it caused by hardware or software.
You need to know how you can still access your data, should the system not boot anymore for whatever reason.
Lose the key or the encryption password and your data is … gone for good.
Have a full backup like @Aragorn said - then you can convert your system to an encrypted one with little effort
/etc/fstab and /etc/mkinitcpio.conf and /etc/default/grub needs to be adjusted - that is essentially all there is to it.
Seems like taking a deep dive into how correctly backup the whole system, and then re-install, is the way to go.
Valid point that having a backup when system is encrypted is a very good idea, so I should probably learn that ins-and-outs first no matter the solution i choose to encrypt.
This is a good point… even when Microsoft can’t scan your Ext4 or BTRFS Partition right now… Windows is a rolling release and who knows if this don’t change overnight.
For that reason, i had installed Manjaro on a external USB SSD Drive from Samsung T5 where im super happy with the performance and i can just unmount it when im loading inside Windows.
I can easily run Timeshift and fix problem without the danger from the Linux Encryption that i run into additional problems.
And for additional security, i can recommend to use Veracrypt on a seperate partition for full partition encryption.
Since there are Telemetry Applications today even under Linux also… like Discord or Steam (and their game Launcher’s) for example.
I realized I’ve used timeshift a few months ago which made the system freak and many apps lose their settings due to storage being full - and it just happened again.
Last time I thought I did it to a network drive, but it went local, and guess it tried to backup all content of the mounts.
This time i ran /home/user /root // (like the root-root) and exception /home/user/Mounts/ where my mount points are for harddrives and networkdrives.
But the same thing happened. Disk went full, system freaked out, and apps lost settings.
It’s a 1TB disk, with about 250gb used. So it shouldn’t backup more than 250gb…
But /timeshift gets 750gb.
With the mounts excluded it shouldn’t really get full.
Why does it fill the disk?
I see /run is 1,1tb on my 1tb disk -how is that? (When writing this I saw another timeshift folder in /run/, at 190gb, I removed that as well and system kinda collapsed, icons removed and such, why is that? and why was it 190gb?)
If I only use use the defaults /home/user + /root (excluding mount points)- will that be enough to fully restore my system exactly as it was?
Hmm, yeah. Deleting /run/timeshift totally destroyed my system. Tried to see if reboot would fix it but wont boot manjoro at all, just go into grub rescue or what it’s called.
No.
That is just user data - your and root’s personal files - but literally nothing from the system.
… I don’t know timeshift - I don’t use it and can’t give any advice …
I doubt that - /run is a temporary directory - probably used to attach the timeshift snapshots in this case.
I think all that deleting it could have done is to destroy/delete your timeshift snapshots.
Is your file system ext4 or btrfs?
The strange apparent inconsistencies may come from you using the wrong tools to assess the free/used space - btrfs has got it’s own tools.
[quote=“Nachlese, post:11, topic:164021”]No.
That is just user data - your and root’s personal files - but literally nothing from the system.
… I don’t know timeshift - I don’t use it and can’t give any advice …[/quote]
Okay, thanks. Good to know!
It happened at the exact second I pressed enter on delete.
But the boot/grub issue might be due to the disk being full for an hour or so. Data that should be persistent just gets destroyed when the system disk manjaro is installed on gets full it seems (at least when filling it up with timeshift backup). Happened both this time and last time.
Perhaps even got to the boot sector and messed that up.
It’s ext4. I think, unable to confirm due to the boot issue, but I remember it as ext4.
Dude, what have you been smoking? And can we have some of that too?
The most common cause is copying/moving stuff into the directory serving as the mountpoint without that the target filesystem is mounted there.
Not on your disk. It’s the used space of all that’s mounted under /run, and some of that actually exists on a tmpfs — i.e. in virtual memory — rather than on disk.
The space was quickly restored by deleting the 750gb /timeshift/ directory.
The problem is restoring the system after the persistent damage it has done.
Damn I hate grub errors. I think I’ll have to start another thread for that.
You know best, of course.
But deleting snapshots doesn’t destroy a system - it literally can’t, for all I know.
[/quote]
More likely the full disk that made the persistent issues yes, and the deletion of run files just crashed the running system, and would’ve booted up nicely if the full disk hadn’t broken stuff before the deletion, like it did last time. But I’m just guessing. It didn’t destroy the boot sector last time…
Confirmed the system is totally destroyed. All files are gone. Just some folder structure and some random files.
Either timeshift wrote over them when it felt it needed more space for the backup. (Don’t think so)
Or some weird links between the backup and the real files was made, so when removing /timeshift and /run/timeshift everything was removed.
Biggest suspect is the /run/timeshift removal. That it’s a really bad idea removing that while timeshift application is running (but not running backup/restoration). My guess it made timeshift restore it all with 0, or something.
And can we have some of that too? 
