rPman

У вас 2 варианта шифрования - на уровне файлов и на блочном уровне.

Первый вариант - самый простой для реализации - в свойствах файла/каталога указываешь флаг шифрования (только для NTFS) и все, только ваш windows аккаунт будет иметь к нему доступ (осторожно, при сбросе пароля или переустановке системы, без резервного копирования ключей шифрования, доступ к данным будет потерян).
Этот способ образно защищает ваши данные от любого пользователя windows но администраторы могут установить приложение, которое сможет скопировать или изменить данные в момент, когда они доступны (администратора же можно создать, имея доступ к железу, загрузившись со специальной флешки).

Второй вариант (bitlocker, truecrypt) защищает весь диск от сторонних пользователей (которые имеют физический доступ к вашему диску), пароль (или ключ шифрования на usb или иной способ) будет запрашиваться при запуске системы (точнее монтировании диска, но не шифровать системный диск в этом случае не имеет смысла), сами данные будут доступны всем пользователям windows на общих основаниях, так будто шифрования нет (но возможны штатные права доступа).

Осторожно, второй вариант отключает использование TRIM у SSD дисков, это очень важная технология, позволяющая ускорить работу с диском и даже продлить его срок службы.

p.s. полная защита данных от тех кто имеет физический доступ к диску - это очень сложный вопрос, в конечном счете задача будет сводиться к технологиям шифрования загрузчика и подтверждения его целостности (например загрузкой своих ключей шифрования в биос материнской платы, такие технологии есть не на дешевых материнках) так как если к примеру вы шифруете диск в датацентре, администраторы этого датацентра могут при следующей перезагрузке подсунуть не настоящее железо, а свое собственное специальное или к примеру хост виртуальной машины, и это железо дождется ввода ключа шифрования и позволит украсть его или данные оперативной памяти а значит доступ к данным. Один из способов борьбы с этим - административный, включение/перезагрузка машины должна проводиться с физическим доступом к ней, с проверкой пломб (корпус не вскрыт, сейф) и личным загрузчиком на флешке/специальном устройстве.

Обычно это нехватка места, по умолчанию настройка своп файла автоматическая если пользователь не сменил настройки.

Своп файл не убьет ваш ssd, даже совсем дашманские диски выдерживают много терабайт записи.

Наверное за исключением если вырожденными случаями не будете пользоваться - к примеру при наличии 8гб ram сделаете своп на 100гб и с помощью ImDisk создадите виртуальный диск в памяти на все 100гб (в этом случае получите очень отзывчивый диск со стратегией lazy writes, когда записываемые данные на диск не попадают на него сразу ни при каких условиях, даже с отключенным кешем на запись а остаются в оперативной памяти).

Если ваши приложения не выходят за границы доступной оперативной памяти, то почти нет никакой разницы где размещать своп файл, особой разницы вы не почувствуете (исключение, топовое железо с десятками тысяч iops, но это явно не ваш случай) т.е. размещайте его на не нагруженном hdd, туда же кидайте hibernate файл, сэкономите десятки гигабайт драгоценного места на быстром диске, иначе лучше оставляйте своп на ssd.