Делаете 2 раздела одного размера. На первый ставите все что надо. Грузитесь с любого юниксового лайвсиди, например frenzy.

dd if=/dev/ad0s1 of=/dev/ad0s2

При восстановлении — просто команда наоборот:

dd if=/dev/ad0s2 of=/dev/ad0s1

Вопрос поставлен не совсем корректно, т.к. может быть 2 трактовки:

1. Если речь идет о веб-скриптах, которые выполняются последовательно, то чем вам не нравится сессия? В данном случае это не костыль — она именно для этого и придумана. Если не нравится непосредственно стандартная реализация, то можно взять собственную (принципиально аналогичную): генерировать ID клиента (сессии) и передавать его через get/post/cookie (по вкусу), а уже сами данные хранить либо в файлах, либо в базе данных, и получать с помощью этого идентификатора в качестве ассоциативного ключа.

Непосредственно данные через куки, гет и пост передавать естественно в данном случае не стоит: эти вещи всегда можно подделать, т.к. они идут через клиента. Это можно назвать костылем :)

================
2. Если же речь идет о выполняющихся одновременно 2 шелл-скриптах, т.е. межпроцессное взаимодействие (IPC), то тут можно использовать разные более или менее системно-зависимых вариантов. От стандартных механизмов IPC: семафоры, сообщения, шаред блок памяти, до специфичных вещей вроде именованного пайпа или сокета; или же аналогичных п.1 вещей (база данных/файлы).

Т.е. я так понимаю, оно пополняться не будет? Если нет — то можно сделать свой велосипед на основе flat файлов с фиксированными длинами полей. Будет быстрая выборка обычными seek. По необходимости [s]присыпать солью[/s] разбить на группы по N записей и хранить в отдельных файлах, именованных согласно (id / N), таким образом файловая система будет частично решать вопросы случайного поиска. Если еще дальше развивать идею, можно попробовать еще разбить по папкам (как например хранит кеш squid).

А если же это дело будет регулярно изменяться, то лучше SQL ничего не придумать. 2 Млн записей — не так уж много, тем более что не нужно по ключам выбирать.

Бо большому счету никак: только у пользователя отрендерить и жаваскриптом опросить. Даже если взять какой-то конкретный браузер, то могут быть разные шрифты установлены, разные размеры базового шрифта в настройках. Не говоря уже о «мелочах» вроде погрешности различных режимов сглаживания. Например в cleartype может «набежать» несколько лишних пикселей в строке, перенесется слово, и дальше уже высота блока сильно вырастет.