Влад Зайцев, нет, TrueCrypt и его деривативы не предполагают расширения.
Криптоконтейнер раскидывает зашифрованные данные по диску, и изменение его размера без перекодирования буквально всего объема не получится.
Тут перекос баланса удобства и надежности - в сторону надежности.
Вам же, видимо, нужны системы, шифрующие на уровне отдельных файлов. Типа предложенных в другом ответе.
Antony Bark, по факту я трахался с этим продуктом, начиная с 4-й версии, когда еще сам работал дизайнером, до купленной в контору версии X3, с которой я, уже как сисадмин, попрощался, когда она перестала ставиться на Десяточку, на которую переехали мои подопечные дизайнеры. Они, кстати восприняли новость об отказе от Корела довольно равнодушно, так как и пользовались им минимально, исключительно для импорта чужих макетов.
Сам же давно сижу на Линуксе, и Inkscape действительно хватает, а когда не хватает - есть другие инструменты, которые просто работают.
Antony Bark, well, buddy, you'd sell me that pen... if I'd really interesting in one. Or another.
Когда мне в прошлый раз понадобился векторизатор, я использовал... а не помню уже, что. Скрипты где-то на работе валялись. А вы с Корелом не расставайтесь, конечно. Эмоции в сторону и все такое.
Сергей delphinpro, главная фигня получится, когда мы потом еще и откроем это "напечатанное" в формате А4, под который обычно заточены программы перевода в PDF, на экранчике меньше А6.
fpir, полагаю, эта история как раз не про SSD.
Я же не говорю, что знаю единственно верный путь, а все остальные - вздор.
Есть разные условия и обстоятельства. Но оценивать их стоит трезво и скептически, без стереотипов, но с анализом юзкейсов.
fpir, хард не будет "столько же стоить", потому что он, внезапно, все равно должен быть установлен под данные. Выделить на нем еще 20 гиг на систему - совершенно не проблема. Можно склонировать образ этой системы, если вам лень ставить ее заново. А моментально при проблемах с диском все равно ничего не исправишь, потому что данные таки придется вытягивать из бэкапа.
Есть, впрочем, один вариант - ставить под бэкап второй такой же сервер, на котором в случае смерти боевого сервера одним заранее заготовленным скриптом меняются имя-адрес-права доступа к шарам, отключается скрипт бэкапа - и он превращается в боевой, пока вы бегаете организовать бэкап с него на погибший. Быстрее рейда будет, кстати.
fpir, ну, так ваш мрущий SSD как раз и проходит по проблеме номер 1.
Недопонимание же между нами возникло по той простой причине, что я не вижу никакого смысла ставить под систему файлопомойки небольшого офиса SSD - только потому, что они шустрее и дешевы. Именно их ненадежность вкупе с (по моему опыту) некритичностью по скорости системного диска для таких задач - лишает эту затею смысла, а уж тем более - если под это добро придется городить рейд из двух SSD.
fpir, рейд решает только две проблемы:
1. Если один из дисков вдруг взял и совсем умер.
2. Если работа с диском на чтение стала узким местом.
Прочие возможные проблемы он не решает совершенно, но при этом, как правило, дает ложное ощущение безопасности, как будто было сделано что-то для сохранности данных. А это не так, поскольку эта задача решается бэкапом, и только бэкапом. При этом бэкап, внезапно, вполне спасает и при первой из озвученных проблем...
По факту, рейд имеет смысл только в двух случаях - если проблема номер 2 действительно требует решения и если работа с дисками настолько суровая, что шанс проблемы номер 1 вырастает до тревожных значений, при этом объем данных, который успевает накопиться между бэкапами, соответственно велик.
Но если мы говорим о файлопомойке для офиса в 40 рабочих мест, это, скорее всего, не тот случай.
А вы уже перестали пить коньяк по утрам? Я этими инструментами вообще-то постоянно пользуюсь.
если у вас 30 лендосов
... на Битриксе? (см. заголовок вопроса)
дев сервер и монтировать его по cifs по мне так вполне нормально
А по мне - так довольно странно. Мои сервера монтируются по sftp / sshfs. Cifs - для SMB-шар.
И если бы вы перед упоминанием прямого подключения к серверу упомянули, что это дев-сервер - я бы и слова против не сказал.
andreevyaroslav, ошибка не "из-за ряда символов", а из-за того, что данные не в той кодировке. Поэтому, пытаясь прочитать их как UTF-8, БД обнаруживает последовательности байтов, которые в UTF-8 не имеют смысла. Вот и выдает вам соответствующую ошибку.
Александр Воробьев, у вас - все так, только для одного удаленщика резонно этот сервер иметь в виде виртуалки на своей же машине и не лохматить зря интернет. Но вы пишете коммент к ответу, в котором совет "да ковыряй просто по фтп, че там".
проект должен иметь только одного разработчика, должен иметь сервер разработки
И на кой ляд одному разработчику - сервер разработки? Особенно ТС, который на домашней-то машинке не может уместить свои халтурки, какой уж ему сервер... Виктор Таран же просто предлагает херачить онлайн по боевому сайту. Во всяком случае, я в его совете не увидел ни единого намека на обратное.
Криптоконтейнер раскидывает зашифрованные данные по диску, и изменение его размера без перекодирования буквально всего объема не получится.
Тут перекос баланса удобства и надежности - в сторону надежности.
Вам же, видимо, нужны системы, шифрующие на уровне отдельных файлов. Типа предложенных в другом ответе.