Что делать, если фрилансер не сделал резервную копию проекта

Что делать, если фрилансер не сделал резервную копию проекта

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

Нужно ли вообще требовать бэкап от фрилансера?

Резервная копия не всегда входит в базовую договорённость. Если вы заказали разовую правку на 2 часа, резервирование часто остаётся на стороне заказчика. Если же фрилансер ведёт проект неделями, меняет структуру сайта, собирает дизайн в Figma, верстает блоки и вносит правки в код, бэкап уже выглядит как разумное ожидание, а иногда и как прямое обязательство из ТЗ.

Тут многое решает формулировка. Одно дело — «сделать сайт по макету», и совсем другое — «вести проект до сдачи, сохранять промежуточные версии и передавать архив исходников». В первом случае спорить сложнее. Во втором у заказчика есть основания спрашивать, почему копия не была сделана на каждом этапе.

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

Какие риски возникают, если резервной копии нет к моменту сдачи?

Главный риск не в самом исчезновении файлов, а в том, что любая доработка превращается в лотерею. Без резервной копии нельзя быстро откатить неудачную правку, сравнить версию «до» и «после», вернуть старую форму, если новая ломает верстку или интеграцию.

Есть и простой, очень приземлённый риск: проект встаёт. Один разработчик уехал, другой ещё не подключён, а на сервере лежит только текущая версия. Исправить мелкий баг уже нельзя без повторной сборки. Час превращается в день. Иногда в три дня. Для бизнеса это означает простои, особенно если речь о магазине, лендинге с платной рекламой или внутреннем сервисе, который нужен «на вчера».

Без копии усложняется и передача проекта другому специалисту. Новый подрядчик смотрит на файлы, видит хаос из финальной версии, старых правок и случайных папок с названием «final2». Восстанавливать историю изменений долго. А если проект подхватывает как найти фрилансера для удаленной работы другой исполнитель, он тратит первые часы не на работу, а на расшифровку чужой логики.

Ещё одна проблема — зависимость от одного источника данных. Если исходники лежат только у фрилансера, заказчик фактически не контролирует проект. Это особенно заметно, когда речь о дизайне, коде и контенте одновременно. Потеря одной папки может сорвать публикацию, а отсутствие копии делает спор о сроках почти бессмысленным.

Что делать, если проект ещё можно сохранить, но бэкапа нет?

Если фрилансер на связи, действовать надо быстро и без драматических сообщений. Попросите сразу выгрузить все доступные исходники: рабочие файлы, экспорт, промежуточные версии, архивы, ссылки на облако, папки с ассетами. Не ограничивайтесь одним файлом проекта. Часто копия «на самом деле» есть, но лежит в другом месте и под другим названием.

Полезно попросить не только итоговую сборку, но и всё, что поможет восстановить структуру. Для сайта это могут быть HTML, CSS, JS, изображения, шрифты, конфиги, JSON, шаблоны CMS, дамп базы. Для дизайна — Figma-файл, экспортированные изображения, иконки, компоненты, стили, комментарии по слоям. Для текста — черновики, версии в Google Docs, история правок. Без этого восстановление будет долгим и местами ручным.

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

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

Как срочно организовать резервирование, если фрилансер уже недоступен?

Когда фрилансер исчез, заказчику приходится собирать проект по кускам. Начните с CMS. Если сайт на WordPress, Tilda, Bitrix или другой платформе, проверьте админку, экспорт, медиатеку, шаблоны, плагины, настройки. У каждой системы свои ограничения, но почти всегда можно выгрузить хотя бы часть контента и медиа.

Дальше смотрите хостинг. На сервере часто остаются файлы проекта, логины к панели, резервные снимки, старые версии сайта, базы данных. На этом этапе полезно подключить того, кто понимает, где искать следы изменений. Если проект шёл через сложную интеграцию, пригодится как проверить надежность фрилансера перед заказом — не как решение задним числом, а как подсказка, где обычно у опытного исполнителя остаются копии и следы работы.

Если использовался Git, проверьте репозитории, ветки и теги. Даже если ветка не синхронизирована, история коммитов может вернуть утраченные правки. В дизайнерских сервисах вроде Figma или аналогов ищите историю версий и права доступа. В облаке — папки с экспортами, автосохранения, общие каталоги, публичные ссылки.

Не забывайте о переписке. В мессенджерах часто лежат файлы, которые в основной папке уже не найти. Почта тоже полезна: там остаются архивы, сметы, черновые PDF, картинки и ссылки на облачные хранилища. Иногда один пересланный архив экономит целый вечер. Иногда два вечера.

Если в проекте участвовали ещё 1–2 человека, проверьте их локальные копии. Верстальщик мог сохранить файлы у себя, менеджер — в общем диске, дизайнер — в отдельной папке на Google Drive. Собирать проект по следам скучно, зато это часто единственный путь не начинать всё с нуля.

Что писать фрилансеру, если он не сделал резервную копию?

Сообщение должно быть коротким и без обвинений. Не стоит начинать с «как так можно было». Так вы только потратите время. Лучше сразу обозначить задачу: передать все доступные файлы, назвать места хранения, помочь восстановить структуру проекта и указать, что уже есть у заказчика.

Подходит такой тон: «Нужны все доступные исходники и копии проекта. Если есть рабочие папки, экспорт, архивы, история версий, пожалуйста, соберите их и пришлите одним сообщением. Отдельно напишите, где хранились файлы и что из этого можно восстановить». Это не ультиматум. Это рабочий запрос.

Если хотите избежать лишних эмоций, пишите по шагам. Сначала запрос на файлы. Потом — на список мест хранения. Затем — на пояснение по структуре проекта: где главная версия, где черновики, где ассеты. Когда есть 3 коротких пункта, переписка обычно идёт спокойнее и быстрее.

Формулировка особенно важна, если заказ связан с коммерческим запуском. В такой ситуации фраза «нужна помощь в восстановлении структуры проекта» звучит полезнее, чем «вы всё потеряли». Люди хуже реагируют на упрёк, чем на конкретную задачу. Это банально, но работает почти всегда.

Когда проблема с бэкапом становится нарушением договорённостей?

Если копия не сделана, это не всегда нарушение. Иногда это просто неудобство и плохая привычка исполнителя. Но если бэкап был прописан в ТЗ, в переписке или в регламенте работы, ситуация уже меняется. Тогда речь идёт не о «неудобно», а о несоблюдении согласованного процесса.

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

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

В спорных случаях помогает договор и история сообщений. Если фрилансер обещал хранить копии 30 дней или передавать архив по завершении этапа, а потом этого не сделал, у заказчика появляется предметный аргумент. Если ничего не было оговорено, ситуация слабее, но и тут можно опираться на переписку, где звучали конкретные обещания.

Как защититься от повторения такой ситуации в будущих проектах?

Лучше всего прописывать резервирование до старта работы. В ТЗ укажите, кто хранит исходники, где лежит рабочая версия, в каком виде передаётся архив и кто делает копию перед финальной сдачей. Если проект длинный, добавьте правило по этапам: после каждого значимого блока создаётся архив и передаётся заказчику.

Не ограничивайтесь общими словами. Пишите конкретно: «передать исходные файлы», «сохранить версию на облаке», «указать доступ к репозиторию», «передать архив проекта с датой». Такие формулировки помогают избежать недомолвок. Если нужен более аккуратный контракт, пригодится материал как составить безопасный договор с фрилансером.

Ещё один полезный шаг — закрепить формат сдачи. Для сайта это может быть zip-архив, доступ к CMS, ссылка на репозиторий и отдельная папка с медиа. Для дизайна — ссылка на Figma плюс экспорт. Для текстов — папка с финальной версией и черновиками. Чем меньше импровизации на финише, тем меньше шансов, что заказчик потом будет искать файлы по переписке.

Хранение копий тоже лучше разделить. У заказчика должен быть свой доступ к облаку, а не только пароль у фрилансера. Если проект сложный, полезно согласовать хотя бы 2 места хранения: рабочее и резервное. Это не панацея, но при сбое одного сервиса спасает день, а иногда и всю сделку.

На практике полезно выбирать исполнителя не только по портфолио, но и по дисциплине. Когда вы заранее смотрите, как он сдаёт этапы и как ведёт файлы, часть проблем отсекается ещё до старта. В похожих ситуациях помогает и материал как выбрать фрилансера для разработки GraphQL, потому что у сильного специалиста почти всегда есть привычка вести проект аккуратно и без хаоса в версиях.

Если проект связан с контентом, версткой или видео, правила лучше сделать ещё жёстче. Передача без архива — не финал. Финал — когда у вас на руках есть файлы, доступы, история версий и понятная структура папок. Иначе через неделю может выясниться, что единственная копия у исполнителя лежит на старом ноутбуке без синхронизации.

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

Если в следующем проекте вы сразу закрепите 3 вещи — место хранения, формат передачи и ответственность за резервирование, — вопрос о том, что делать если фрилансер не сделал резервную копию проекта, просто не всплывёт на финише.