alexalexes

Потому, что у вас в коде происходит обход только по текущему уровню каталога $dir.
Чтобы обход заныривал глубже, нужно создать рекурсивную функцию.
Телом рекурсивной функции у вас будет:

if ($dh = opendir($dir))
{
// код, который у вас в вопросе
}

А точка вызова для смены подкаталога:

if (is_file($dir.$file)) {
// код из вопроса
            }
else if(is_dir($dir.$file))
{
   $zip->addEmptyDir($dir.$file);
   // тут должен быть вызов рекурсивной функции, по которой вы передаете контекст $zip и $dir.$file (наверное, передача по ссылке)
}

В этом случае у вас будет рекурсивный обход каталогов в глубину.
PS: Проконтролируйте дескриптор $zip на больших вложенностях и большим содержании файлов, нет ли переполнения выделенной оперативной памяти. Еще стек вызовов функций не бесконечный, тоже проконтролируйте глубину вызова.
PPS: Бэкапить сайты в архив делается одной строчкой линуксовой командой, и засовывается в crontab. Будет работать надежнее. Эта не задачка для php-разработчика.
То, что вы делаете - это просто тренировка на кошках, как работать с ZipArchive в PHP.

Вот такие проектировщики плодят кучу таблиц под одну сущность.
Яркий пример, под каждый год отчетности создают таблицы <название_таблицы>_<год_отчетности>.
Не надо так, пожалуйста.
В вашем случае, ситуация ровно таже самая.
Добавьте в существующий статус задачи еще одно значение - "Архивный", либо создайте отдельный атрибут под этот признак. И, обязательно, проиндексируйте его.
В бизнес-логике очень легко отсеять записи с неподходящим статусом.
Если не хотите, чтобы бизнес-логика видела ненужные записи, делайте для нее свое view.
Есть, конечно, случай, когда таблица становится очень большой, и нужно облегчить накладные расходы по ее хранению, то в этом случае настраивают партиции таблицы. Но это тонкое администрирование.
PS: Если задача требует переноса данных в один присест и это не ошибка проектирования архитектуры, то это выполняется как любое неэлементарное действие с помощью транзакций в процедурном режиме выполнения SQL:
- открываем транзакцию;
- делаем insert с select;
- делаем delete;
- закрываем транзакцию.
Только имейте ввиду, что в транзакции не должны прогонятся длинные выборки ни в insert-е, ни в delete. Это влияет на время блокировки таблиц, и сильно затратно по производительности, так как существенно перестраиваются индексы. Нужно аккуратно использовать такие процедуры (по правилу: "семь раз селекть, один раз делеть"), иначе получите залочивание на длительный период.

Если текст написан символами только из 7-битного диапазона (классический английский текст), то кодировку вы не определите. Он будет нормально читаться в любой кодировке. Вам все равно придется выбирать ту кодировку, свойственную текущему программному окружению.

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