В процессе разработки сайта на Django пришлось начать разбираться с Bash скриптами, чтобы автоматизировать рутинные задачи. Например, создание и скачивание дампа базы данных с сайта, а также резервирования медиа файлов.
Будем считать, что что Вы уже имеет доступ к серверу через ssh , а у вашего пользователя на сервере, который управляет сайтом есть права доступа, с помощью которых он может делать дамп базы данных.
Структура каталога со скриптами
Для выполнения резервирования медиа файлов и дампа базы данных потребуется написать несколько скриптов:
- Основной скрипт
- Скрипт для создания дампа, который будет выполняться на удалённом сервере
- Скрипт для удаления дампа на удалённом сервере, чтобы не тратить зря драгоценное дисковое пространство
Структура будет следующей
./remote-scripts/create_dump.sh ./remote-scripts/remove_dump.sh ./backup.sh
create_dump.sh
Когда пользователь входит на сервер, он оказывается в своей домашней директории. Поэтому и скрипты будем писать исходя из того, что находимся в данной домашней директории.
#!/bin/bash # Запомним время создания дампа current_date=$(date +"%Y_%m_%d_%H:%M:%S") # Создадим директорию, куда сохраним дамп mkdir db_dumps # создадим дамп pg_dump database_name > ~/db_dumps/db_$current_date # отключимся от сервера exit
Я создаю директорию для дампа потому, что так проще будет скрипт для вызова rsync, просто сливаем весь дамп в какую-нибудь директорию и всё. При это другие версии дампа, которые мы скачали раннее не будут удаляться, даже если они не существуют в директории db_dumps.
remove_dump.sh
Скрипт для удаления дампа с удалённого сервера
#!/bin/bash # удалим директорию с дампом базы данных rm -rf db_dumps # отключимся от сервера exit
backup.sh
А теперь время для самого главного скрипта, который всё соберёт вместе
#!/bin/bash # Пути к скриптам REMOTE_SCRIPTS_PATH="remote-scripts" SCRIPT_PATH_CREATE_DUMP="create_dump.sh" SCRIPT_PATH_REMOVE_DUMP="remove_dump.sh" # Создадим дампа базы данных ssh username@111.222.333.444 'bash -s' < "$REMOTE_SCRIPTS_PATH/$SCRIPT_PATH_CREATE_DUMP" # Скачаем дамп в каталог backup rsync -av --progress username@111.222.333.444:~/db_dumps ~/backup # Скачаем медиа файлы в каталог backup rsync -av --progress username@111.222.333.444:~/virtual_env/yourproject/media ~/backup # Удалим дамп с удалённого сервера ssh username@111.222.333.444 'bash -s' < "$REMOTE_SCRIPTS_PATH/$SCRIPT_PATH_REMOVE_DUMP"
В данном случае делаем подключение по ssh с указанием имени пользователя и IP адреса сервера.
Данная строка передаёт на исполнение на удалённом сервере скрипт create_dump.sh с вашего локального ПК
ssh username@111.222.333.444 'bash -s' < "$REMOTE_SCRIPTS_PATH/$SCRIPT_PATH_CREATE_DUMP"
Приветствую! а почему pg_dump, а не Django'вское dumpdata?
Добрый день!
так ./manage.py dumpdata > db.json дампит всю бд. но привычка это да, согласен
не нашел как редактировать комент...
да да. я понял, что оно может дампить всю базу, просто если функционал БД позволяет дампить всю базу и нет необходимости в дополнительном функционале, то и искать нет необходимости что-то ещё. Просто dumpdata, следуя документации, может дампить приложения по отдельности.
Единственное, в чём недостаток этого dumpdata, по моему мнению в том, что он скорее всего будет медленнее работать, чем средства БД, как никак дополнительная обвязка на питоне. Может быть критично для выконагруженных сервисов.
Редактирование комментариев я пока не прикручивал к сожалению, редактирование есть только на форуме. увы.
медленно, особенно на больших объемах - совсем печаль. я храню, но только на локальных проектах.
один вопрос меня мучает уже давно...это не даже не про бэкап.
Поточнее пожалуйста, не совсем понял про счётчик объектов Джанги.
допустим у нас есть любая таблица, созданная джангой. через админку добавляем пару записей. все ок.
Вон оно что. Не сталкивался с таким, надо будет глянуть исходники дефолтного менеджера объектов. Возможно там кеширование просто.
не, с тех пор боюсь делать такое)
Ну я же не предлагаю на боевом сервере )))