У процесі розробки сайту на Django (https://evileg.com/knowledge/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, по моему мнению в том, что он скорее всего будет медленнее работать, чем средства БД, как никак дополнительная обвязка на питоне. Может быть критично для выконагруженных сервисов.
Редактирование комментариев я пока не прикручивал к сожалению, редактирование есть только на форуме. увы.
медленно, особенно на больших объемах - совсем печаль. я храню, но только на локальных проектах.
один вопрос меня мучает уже давно...это не даже не про бэкап.
Поточнее пожалуйста, не совсем понял про счётчик объектов Джанги.
допустим у нас есть любая таблица, созданная джангой. через админку добавляем пару записей. все ок.
Вон оно что. Не сталкивался с таким, надо будет глянуть исходники дефолтного менеджера объектов. Возможно там кеширование просто.
не, с тех пор боюсь делать такое)
Ну я же не предлагаю на боевом сервере )))