Кошерное хранение информации

[Sibiryakoff]

Добрый день!
Уважаемые коллеги, давайте поделимся друг с другом опытом корректного хранения и архивирования больших объемов информации: в случае препресс-бюро, типографии или дизайн-студии.
1. Техническая часть
2. Логистика процесса

Мой вариант, дизайн-студия, 10 человек.

1. Сервер с зеркальным RAID-массивом 2х250 ГБ, архивация на СД - ДВД, в 2х экземплярах.
2. Папки с работами в процессе хранятся на конкретных компьютерах. Выполненные работы 3 месяца хранятся на сервере. Те, которые могут потребоваться в любой момент - постоянно. После 3-х месяцев невостребованные работы из архива скидываются на СД / ДВД в 2-х экземплярах.
Структура папок: по заказчикам (алфавит) > по направлениям > по проектам > исходники / рабочий материал / готовый материал (архивируется рабочий материал / готовый материал). Диски сортируются по заказчикам > по дате записи.

Ваши варианты?

 

[Flame]

Ответ: Кошерное хранение информации

2. Папки с работами в процессе хранятся на конкретных компьютерах.

Вот это неправильно.
1) Десктоп по определению не обладает надежностью сервера (нет рейда с резервированием итп) -- вероятность потерять файл из-за сбоя больше
2) При работе непосредственно на сервере и подлинковывании файлов с сервера же исчезает необходимость апдейта линков при переносе верстки между сотрудниками

Структура папок: по заказчикам (алфавит) > по направлениям > по проектам > исходники / рабочий материал / готовый материал (архивируется рабочий материал / готовый материал). Диски сортируются по заказчикам > по дате записи.

Ваши варианты?

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

 

[tatarin]

Ответ: Кошерное хранение информации

сто лет пользуюсь подобной схемой ни разу ничего не потерял, не напрягаю мозги, чтобы помнить где чего лежит.
Передать с машины на машину или сархивировать -- просто перекинуть папку с проектом, отдать заказчику -- прибить src и art.
Название проекта: год_номер заказа.
В сырцах все что приходит от заказчика (включаяя переписку по мейлу)
В арте всяческие временные и промежуточные файлы, профиля и тд и тп.
Fonts -- no comments.
В корне -- публикация и линки.

 

[tatarin]

Ответ: Кошерное хранение информации

Вот это неправильно.
1) Десктоп по определению не обладает надежностью сервера (нет рейда с резервированием итп) -- вероятность потерять файл из-за сбоя больше

Это как раз правильно.
Не стоит напрягать сетку без надобности!
Скопировать вечерком проект на сервер это не то, что вдесятером поскрипты генерить.

2) При работе непосредственно на сервере и подлинковывании файлов с сервера же исчезает необходимость апдейта линков при переносе верстки между сотрудниками

А как ты думаешь почему публикация и линки в одном месте лежат?

 

[@diz@]

Ответ: Кошерное хранение информации

Кстати интересно и то, как фрилансы хранят свою информацию.
На чём, сколько копий. Если много разъездов и есть нотик - здесь понятно. А если без него, то кто чем пользуется для переноса данных. Интересно также, какие "ящики с инструментами", чтобы оперативно создать себе удобное рабочее место для работы на чужом компе.

 

[inTurisT]

Ответ: Кошерное хранение информации

2х250 ГБ маловато будит

 

[tatarin]

Ответ: Кошерное хранение информации

Кстати интересно и то, как фрилансы хранят свою информацию.
На чём, сколько копий. Если много разъездов и есть нотик - здесь понятно. А если без него, то кто чем пользуется для переноса данных. Интересно также, какие "ящики с инструментами", чтобы оперативно создать себе удобное рабочее место для работы на чужом компе.

Ящик с инструментами -- комп, USB-клава. (Комп-Mac-mini, клава резиновая).
Дискета в 40 Гбайт. набор шнуров-переходников, Bluetoos, набор мышей.


Кстати на X под каждый проект завожу юзера. Удобно просто супер. Все настройки под конкретный проект сохраняются и применяются автоматически.

 

[dimmon]

Ответ: Кошерное хранение информации

Кстати интересно и то, как фрилансы хранят свою информацию.
На чём, сколько копий. Если много разъездов и есть нотик - здесь понятно. А если без него, то кто чем пользуется для переноса данных. Интересно также, какие "ящики с инструментами", чтобы оперативно создать себе удобное рабочее место для работы на чужом компе.

Создал специальный backup раздел прогой Partition Magic и скидываю туда периодически важную инфу - текущая работа, бэкапы почты и тд и пр.
А "ящик с инструментами" это просто - любимые проги (включая *.kys, плагины) на флэшку и вперед! Ну может скоро задумаюсь над своим фтп-сервером небольшим.

Собственного опыта потери инфы не имею, но наблюдал (в издательстве), как огромное количество файлов с кириллическими именами ушло в небытие, долго мучались, какую-то часть восстановили с трудом. С тех пор называю файлы только латиницей. Не только себе хорошо, но и на фотовыводе ребята не ругаются

 

[tatarin]

Ответ: Кошерное хранение информации

Создал специальный backup раздел прогой Partition Magic и скидываю туда периодически важную инфу - текущая работа, бэкапы почты и тд и пр.

Не кошерно. Бацап должен быть на отдельном девайсе, желательно территориально удаленном.

А "ящик с инструментами" это просто - любимые проги (включая *.kys, плагины) на флэшку и вперед! Ну может скоро задумаюсь над своим фтп-сервером небольшим.

А у меня так и происходит. Благо в десятку это встроено. iDisk, и ваш персональный ФТП в Купертино

Собственного опыта потери инфы не имею, но наблюдал (в издательстве), как огромное количество файлов с кириллическими именами ушло в небытие, долго мучались, какую-то часть восстановили с трудом. С тех пор называю файлы только латиницей. Не только себе хорошо, но и на фотовыводе ребята не ругаются

И сколько раз твердили миру, что надо восемь точка три.
Еще во времена царя гороха (NT4SP2) была придумана система префиксов.
Creater-Project-Page-Count_Любой текст.ext
P3260011 Иллюстрация к проекту 326 на первую полосу номер 1.tif
Когда слетают длинные имена, остается P3260011.tif
Перелинковать особых проблем нет
Постепенно надобность в пояснительном тексте пропадает, да и набивать его становится лениво.

 

[oxygen777]

Ответ: Кошерное хранение информации

У нас так. Прежде чем начать дизигнер создает в базе данных запись которая хранит все необходимые сведения о проекте. За это клиент (то есть, программа которая осуществляет интерфейс БД) создает дизигнеру в указанной рабоче папкей структуру каталогов с нуль-файлами. То есть, просто файлы ai, cdr, psd, и тп с базовым названием по имени родительской папки и с дополнениями в виде всяких номеров, суффиксов и тп. Если указан шаблон - то может скопировать файлы шаблона переименовав в соответствии с.

... тут дизигнер работает ...

если ему нужно записать файл то он не набирает его имя вручную в окне Save As, а просто выбирает один из подходящих нуль-файлов в той или иной папке. Причем есть надстройка и над файлами - но косвенная. Имена файлов отображаются сокращенными по базовому имени папки проекта в специальном окне, где перечислены текущие проекты в разной стадии готовности. Там иерархический список, как в Проводнике слева. Так что диалогами Open\Save As можно вообще не пользоваться.

Разумеется название папки практически никакого значения не имеет - живьем по папкам редко кто лазит: в кэше тысячи папок и одно перечисление их в список занимает минуту в Проводнике. Если нужно открыть какую-то - находите в базе запись искомого проекта и среди множества полей есть Folder. Прямо из клиента можно открыть эту папку если она есть в кэше на сервере. Если там нет, то придется сначала вставить компакт-диск, номер которого фигурирует тут же - в одном из полей записи.

... тут дизигнер закончил работу ...

После того как работа над проектом или его частью закончена, файЛо отправляется на сервер, в кэш. Отправляется НЕ вручную, а с помощью того же клиента БД. Там есть специальная функция-дистрибутор. Папка с готовой работой обрабатывается: удаляются неиспользованные нуль-файлы, папка копируется на сервер, затем копируется в локальный бэкап юзера, и только затем удаляется из рабочей папки. После успешной обработки запись данного проекта помечается "готов".

Раз в месяц с помощью того же клиента БД создаются образы компакт-дисков для архивирования. Программа запрашивает базу, типа "какие записи не имеют номера архивного СД" и получив список шерстит кэш - ищет соответствующие папки. Найдя, копирует их, заполняя по 700Мб вновь создаваемые папки, откуда потом осуществляется прожиг.

Время от времени запускается проверка поиска неактуальных проектов и их папки удаляются из кэша (но на СД они остаются навсегда).

Там еще много чего наверчено: делаются превьюхи, переименование папок идет тоже через клиента БД. В клиенте масса фишек, типа Favorites, Fonts. Сама БД распределенная - несколько групп работают в разных местах. Сбор дизигна для печати идет тоже по базе. 100мегабитная сетка и быстрые винты никаких проблем не создают. Распределенные группы соединены через инет, там помедленнее, но через инет и не выводится - сначала от них выкачивается в кэш. Выкачивается за бесплатно - внутри адресов одного провайдера все без денег.

То есть, система настроена на то, чтобы вообще избавить дизигнера о мыслях по учету дизигна. Единственное требование - строжайшая гигиена пользования базой. То есть, сначала надо проверить - нет ли такой или похожей записи, а затем уже вносить новую. Это все. Больше дизигнер ручками ничего не вписывает, папок не создает и не называет, файлов не называет. Либо использует нулевые, либо валит из входящих - исходники, тексты, клипарты, логотипы и прочий хлам.

 

[tatarin]

Ответ: Кошерное хранение информации

Вообще-то в идеале базой должен рулить манагер.
А дизайнер получать по почте бриф, и работать уже в ГОТОВОМ проджекте.
Чем меньше лишних движений, тем меньше шансов оказаться в Ж...

 

[oxygen777]

Ответ: Кошерное хранение информации

Когда слетают длинные имена, остается P3260011.tif

Куда слетают?

Однако интересное замечание. Буквально эта проблема и вызвала к жизни вышеописанное решение. Дело в том что Кварк когда-то давно не понимал длиных имен файлов. И такое было мнение что называть длинно нельзя. И не называли. А базы - не было. В результате отыскать папку давнишнего проекта чтобы внести коррективы и еще отпечатать - стало просто невозможно: никто не помнил комбинацию из 8 символов того, что в целое предложение только укладывается.

Но однажды Василий Иванович заметил что сарай без крыши - кто-то ошибся со счетом и назвал папку в 9 символов. И ничего, Кварк все заглотил и вывел! Балин! Анекдот, буквально. Кто-то в конторе сказал: низзя больше 8.3 и все поверили - никто не проверял. Но к тому времени уже был налажен учет работы с помощью клиента базы данных.

Кстати, нужна реляционная база данных, а не електронная таблица как в ёкзеле. Многие начинают учет как раз с этого чюда - с екзеля. Это только оттягивает катастрофу.

 

[Avdot]

Ответ: Кошерное хранение информации

У нас так....

А что за софт? Или это собственная разработка?

 

[MrDesigner]

Ответ: Кошерное хранение информации

И сколько раз твердили миру, что надо восемь точка три.

Вы бы ещё DOS вспомнили...

 

[Avdot]

Ответ: Кошерное хранение информации

Вы бы ещё DOS вспомнили...

Но с русскими-то (не английскими даже) символами правы.

 

[tatarin]

Ответ: Кошерное хранение информации

Вы бы ещё DOS вспомнили...

Гы-ы-ы...
Оттуда уши и ростут.
В 95 еще винде, где FAT была, имелось у файла два имени, досовское (то, что четез тильду) и длинное, которое воспринималось некоторыми программами как сбой и игнорировалось. Префикс для того и был сделан, что бы по досовскому имени можно было понять, что за файл.
Система префиксов была содрана с некоторй штуки под названием System 6.
Году в 96 такая стояла на Правде в ООТИИ.
Кстати попытки верстальщиков, дизайнеров и т.д. использовать длинные имена надо пресекать в зародыше.
Сравните:
C:/Documents and Settings/Vasya Batareikin/Desktop/Рога и Копыта/Визитки/eng/Генеральный директор/визитка Генерального Директора.cdr или
W:/254/src/viz.cdr
Краткость -- сестра таланта

 

[oxygen777]

Ответ: Кошерное хранение информации

Avdot Собственная. Был момент - хотели найти что-то из готового, но обломились и стали развивать свою дальше.

Сравните:
C:/Documents and Settings/Desktop/Рога и Копыта/Визитки/eng/Генеральный директор/визитка Генерального Директора.cdr или
W:/254/src/viz.cdr
Краткость -- сестра таланта

254 это что? А для "Визитка зама генерального директора.cdr" какой код?

 

[tatarin]

Ответ: Кошерное хранение информации

Это абсолютные пути к файлам, какими их возвращают окна типа open, print, get picture, place и прочие
А 254 это номер заказа.
W - диск, на котором хранятся работы (Works).
А для "Визитка зама генерального директора.cdr" кода нет. Это файл от клиента.

 

[Avdot]

Ответ: Кошерное хранение информации

у нас попроще.
не говорю что грамотнее.
папка CLIENT (его абривеатура или название)
|
CLN-001 (номер заказа)
|
+--END (храниться только конечный вариант)
+--Photos (фото материаллы)
+--txt (txt материаллы)
+--Original (материаллы заказчика)
+--Work (рабочие материаллы)

В корне заказа лежат файл бланка заказа и перепика с клиентом.
Менеджеры ведут файл прохождения заказов, с указанием дат, исполнителей и т.п.
Сис. адм. бекапит закрытые заказы. Папка с № заказом не удаляеться.
внутри нее находиться файл с именем "Заказ преренесен на DVD-00X.txt"

Некоторые отступления допустимы.

 

[tatarin]

Ответ: Кошерное хранение информации

Весма избыточно.
Неужели у разных заказчиков могут быть одинаковые номера заказов?
txt и original разве не могут быть объединены?
Фотоматериалы это что? Сканы?

У меня суть папки src в том, что это DropBox с возможностью ReadOnly
Из корня рабочего диска я попадаю в проджект и сразу виден головной файл.
А у вас? Disk:->Client->number->end->file

Хотя в принципе примерно такая же система. Только более громоздкая.