Резервное копирование linux на яндекс диск
Правильное создание и безопасное хранение бэкапов задача важная и необходимая. Можно относится халатно, но тогда в случае проблем можете обнаружить что резервных копий нет или они просто испорчены.
Из статьи вы узнаете как я подхожу к этому вопросу и защищаю бэкапы всех своих ресурсов надежно и безопасно в системах Linux.
В примере будет рассмотрен вариант для резервного копирования файлов и базы данных сайта, но можно этот подход использовать и для других задач.
Можно использовать для резервных копий разные программные комплексы или пользоваться средствами которые предоставляют хостинги, но для этого необходимо их изучать или производить финансовые затраты. Лично я предпочитаю использовать механизмы проверенные временем и хранить все бэкапы на своих ресурсах.
Создание бэкапов на сервере
Самое надежное это когда производится создание резервных копии на самом сервере, так как это гарантирует что вы не получите проблем возникших с удаленным подключением к сторонним ресурсам. Например, при использовании бэкапа на Yndex Disk у меня периодически были ошибки при создании бэкапа.
Установка Davfs2
Рассмотрим настройку на примере системы CentOS 7.
Подключим репозиторий Еpel:
Установим пакет davfs2:
Основа безопасности бэкапов
Правильность и безопасность бэкапов включает в себя несколько простых правил:
- Хранение бэкапов за продолжительный период времени. Вариантов почему лучше хранить бэкапы долго множество. Например, удалили какой то материал, но решили восстановить спустя некоторое время или необходимо найти ошибку когда появилась проблема которую обнаружили не сразу.
- Забарать бэкапы сторонним сервером. В идеале лучше использовать под резервные копии специальный сервер использующийся только для бэкапов. В случае если копии бэкапов отправляются с самого сервера где делаются бэкапы это опасно, так как в случае взлома или вируса вы можете потерять все копии.
- Мониторинг как создание бэкапа так и аналитика его размеров. Как бы вы не пытались отслеживать периодически сами как делаются бэкапы по закону подлости, когда они потребуются, обнаружите что они или не делаются или испорчены.
Ниже я по порядку опишу все свои действия которые использую на практике. Будут использованы стандартные программы используемые во всех версиях Linux.
Создание копии backups используя rsync
В моем случае под всевозможные бэкапы используется специальный сервер настроенный только для бэкапов.
Подключается к серверу с которого надо забирать бэкапы будем по сертификату. Для копирования будем использовать утилиту rsync.
Именно на этом сервере производится мониторинг правильности создания бэкапов и их размеры средствами программы для мониторинга Zabbix.
Узнать как работать со свободным программным комплексом для мониторинга вы можете из раздела Мониторинг Zabbix.
Возможности Zabbix удовлетворят любые потребности для осуществления любых параметров практически любой системы.
Добавление задания в cron
Обязательно учитывайте время когда делается первый бэкап, так как дальнейшие копии сделанных бэкапов надо делать позже по времени для избежания путаницы и правильного мониторинга.
В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времени которое необходимо для создания бэкапа.
Открываем необходимый файл и добавляем нужный код:
Согласно команде каждый день в 6:30 бедет выполнятся скрипт который будет забирать резервные копии согласно вашим пожеланиям.
Дальнейшие проверки аналогичны действиям указаным в разделе выше.
В случае вывода ошибки при выполнении скрипта:
Смотрите правильность указания всех путей и параметров или выполните в консоли команду rsync —help и разбирайте в параметрах команды.
Проверка создания бэкапов
Убедится что все работает правильно можно только запустив скрипт у посмотреть результат его работы.
Мне больше нравится брать код непосредственно из файла crontab, так как это последнее место которое выявит ошибки связаные с правильностью написания пути к скрипту.
Из вывода видно какие файлы забекапились и что база данных тоже успешно зарезервиловалась.
Осталось дождаться времени выполнения и проверить как отрабатывает команду cron.
Посмотреть результат работы cron можно заглянув в файл:
Никогда не игнорируйте проверку резервных копий и обязательно настройте надежную систему мониторинга.
Настройка WebDav для Yandex.Disk
Создадим папку куда будем монтировать:
Чтобы не путаться в конце я указываю логин почты на котором находиться диск.
Смонтируем Yandex.Disk в необходимую папку:
Диск смонтировался в указанную папку.
Отмантировать диск можно командой:
Введение вручную данных при монтировании не всегда удобно и для удобства мы автоматизируем этот процесс.
Отредактируем файл /etc/davfs2/secrets, добавив в конец строку с данными для авторизации:
Так мы можем задать любое количество строчек с необходимыми ресурсами Yandex.Disk.
В случае если вы хотите чтобы диск монтировался при перезагрузке системы то в etc/fstab необходимо добавить строчку:
Теперь при перезагрузке сервера диск автоматически монтируется.
Не советую использовать монитрование через fstab, так как в случае обрыва связи копии не будут копироваться.
Можно конечно настроить механизм который будет окнтролировать это подключение и поднимать его в случае обрыва, но мне это кажется ненужным усложнением.
Как разархивировать архив
Если в дальнейшем потребуется восстановить резервные файлы на сервере, то воспользуйтесь рекомендациями из статьи «Как быстро восстановить резервную копию на сервере».
Кстати, на сайте нет рекламы. У сайта нет цели самоокупаться, но если вам пригодилась информация можете задонатить мне на чашечку кофе в макдаке. Лайкнуть страницу или просто поблагодарить. Карма вам зачтется.
Структура папок для бэкапов
Создавать папки можно где угодно. Например, мне больше нравится создавать их в корне папку backup и держать там всё что связанно с резервными копиями.
Создадим необходимые папки куда будем класть бэкапы
В итоге мы получили следующие папки:
Создание скриптов для бэкапов
Создадим два скрипта для ежедневного и ежемесячного бэкапа.
Создадим скрипт который будем ежедневно запускать по расписанию:
Для ежемесячных бэкапов создадим такой скрипт:
Первая и последняя команда в обоих скриптах взаимоисключающие. При варианте когда мало места и есть возможность хранить только один бэкап первая команда должна выполняться а последняя нет. В случае достаточного места под бэкапы первую команду не выполняем а в последней выставляем количество дней за которые хранятся бэкапы.
После создания скриптов сделаем их исполнительными выполнив необходимую команду:
Использование Yndex.Disk для backups
При регистрации домена мне нравится переводить его управление на Yandex. Для бэкапов создаю отдельный почтовый ящик на домене и туда копирую бэкапы сайта. Удобно передовать заказчику управление доменом и резервные копии в одном месте.
Yandex.Disk дает возможность подключится с помощью WebDav. Необходимо добавить пакет davfs2 для работы по WebDav.
К сожалению на данный момент невозможно передавать данные большого размера по WebDav на Yandex.
Вы можете установить на систему консольный клиент от Yandex и проводить резервное копирование с помощью его.
Официальная страница руководства пользователя имеет понятное описание по установке и использованию на разных системах.
Более подробно с описанием сервиса Yandex Disk вы можете ознакомиться перейдя в раздел техподдержки Яндекса.
Комментарии к статье “ Монтирование Яндекс Диска по протоколу WebDAV (CentOS) ” (4)
Отдельные директории на Яндекс диске можно примонтировать к разным директориям на сервере?
Можно. В этой статье и по ссылкам в ней всё это описано.
После ребута пропадает монтирование, как настроить автомаунт?
Добавлял /etc/fstab строку:
По вашему вопросу не подскажу, но чем плохо монтирование диска перед самой процедурой бэкапа?
18.12.2019
VyacheslavK
CentOS, Linux
Комментариев пока нет
Не так давно, мы размещали статью о подключении популярных бесплатных облачных хранилищ на сервере с CentOS 7. В этой статье мы покажем, как можно использовать данные хранилища для резервного копирования данных с вашего сервера. Я использую эти скрипты для дополнительного резервного копирования файлов сайта и базы данных со своего Linux VPS сервера.
Создание скрипта для работы с Yandex.Disk
Создалим скрипт для выполнения копирования резервных копий на Yandex.Disk:
Скрипт выполнит следующие действия:
Очищать кэш созданный при работе davfs2 надо обязательно иначе место на диске быстро закончиться.
После создания скриптов дадим необходимые права для всех файлов в папке backup:
Создание скрипта для выполнения rsync
Создадим необходимый скрипт:
Скрипт задокументирован и выберите параметры исходя из ваших требований.
Расшифрую параметры указанные в коде:
- a — режиме архива;
- v — увеличение детализации;
- z — сжатие данных файла во время передачи;
- h — вывод чисел в удобочитаемом формате;
- e — используем ssh подключение.
После создания скриптов сделаем их исполнительными выполнив необходимую команду:
Скрипт бекапа на Яндекс.Диск из Linux
Данное облачное хранилище я оставил на закуску, так как резервное копирование в Яндекс.Диск является самым простым, т.к. мы смонтировали облачное хранилище Яндекс через WebDav как отдельное дисковое утсройство . Способ все тот же, мы запускаем скрипт, только лишь с небольшой разницей, не нужно делать синхронизацию или заливку файлов специальными командами, работаем как с обычным серверным каталогом. Синхронизация каталога выполняется с помощью rsync. Скрипт будет иметь вид:
Все тоже самое, только без лишних команд. Если у вас другие пути до облачных хранилищ, меняйте в скрипте на свои.
В конце статьи хотелось бы добавить. Я разместил указанные скрипты в отдельную директорию и запускают их по крону. Если дисковое пространство на ваших облачных дисках позволяет часто создавать бэкапы, создавайте их как можно чаще, я рекомендую не реже одного раза в 3 дня. Используйте ресурсы облачных хранилищ на все 100%.
Примеры заданий в кроне:
0 0 * * 6 /root/bin/backup.sh — запускаем скрипт бэкапа каждую субботу в 00-00
0 0 */3 * * /root/bin/backup.sh — запускаем скрипт бэкапа каждые 3 дня в 00-00
И так далее, настройте бэкапы как вам удобно, когда нагрузка на сервере минимальна.
Добавление задания в cron
Откроем для редактирования /etc/crontab файл откуда выполнятся задания:
Перезагрузим cron в системе CentOS 7 для применения изминений:
Проверки осуществляем по аналогии с предыдущими главами.
Сохраняем резервные копии на Яндекс.Диск
Теперь пора заняться сохранением резервных копий сайта на Яндекс Диск. Ниже будут два варианта.
Выбираете тот способ, который покажется вам удобнее или проще.
Устанавливаем и настраиваем WebDAV для Яндекс.Диск
Устанавливаем на CentOS WebDAV:
Добавляем данные аутентификации Яндекса в специальный файл:
Если возникает ошибка:
Тогда устанавливаем редактор nano.
Создаём на сервере папку Яндекса, которую будем подключать:
Монтируем Яндекс Диск:
Вводим логин и пароль от Яндекса. Пароль хранится незашифрованном, чтобы не скомпроментировать свои данные, создайте отдельный пароль для приложения WebDAV.
Ввод логина и пароля может не понадобится, если вы заполнили в предыдущем действии файл /etc/davfs2/secrets.
Команда для размонтирования диска:
Не будем добавлять автоматическое монтирование Яндекс Диска при каждой загрузки Linux. Это не рекомендуется делать, потому что для резервного копирования диск нужен лишь на короткое время. Вместо этого будем монтировать диск на время работы скрипта.
Добавление заданий в cron
Время в которое необходимо выполнять выбирайте на свое усмотрение. В большинстве случаев лучше использовать ночное время так как в это время сервера загружены минимально и можно использовать их ресурсы для выполнения своих внутренних задач.
Обязательно учитывайте время когда делается первый бэкап, так как дальнейшие копии сделанных бэкапов надо делать позже по времени для правильного мониторинга.
В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времини которое необходимо для создания бэкапа.
Открываем необходимый файл и добавляем нужный код:
Согласно команде каждый день в 1:20 бедет выполнятся скрипт для создания ежедневного бэкапа и ежемесячно первого числа в 1:25 будет создаваться ежемесячная резервная копия.
Перезагрузим cron в системе CentOS для применения изменений:
Backup и его периодичность
Всегда сложно выбрать какой необходим период хранения и интервал резервного копирования. Для меня удобней организовать резервное копирование по следующей схеме:
- Дневные копии — хранить 30 дней,
- Месячные копии — хранить год.
Подход к резервированию сугубо личное дело и зависит от множества факторов. Главное чтобы эти копии всегда были доступны, исправны и удовлетворяли вашим требованиям.
Исправление ошибок во время монтирования:
Заключение
Постарался описать максимально понятно все варианты которые я использую при создании резервных копий данных сайтов. В случае если вы найдете ошибки или знаете как можно улучшить данные примеры пожалуйста напишите в комментариях к статье.
Не могу разобраться как настроить backup VDS на Яндекс.Диск. Прочитал много статей, включая хабр (либо старые, либо не работает). Попалась одна нормальная статья. Смысл в том, что не требуется дополнительная установка каких-либо утилит на сервер типа "davfs2". А просто получение токена и использование его в скрипте по крону. Только вот скрипт не рабочий, а с написанием скриптов на баше, проблемы.
Пытаюсь сделать бекап как сайтов на сервере, так и БД + настройки и утилиты VDS (что касается последнего, я даже не знаю, что конкретно нужно бекапить + как восстанавливаться в случае чего).
- Вопрос задан более трёх лет назад
- 6623 просмотра
Оценить 13 комментариев
mureevms:
1. Как написано в вопросе, не хотелось бы что-либо лишнее устанавливать на сервер, когда понимаешь, что есть другой путь.
2. В данной статье не описаны бекапы, ну установлю я Яндекс.Диск на сервер и что? - Все мои данные перейдут на мой сервер? - Ок, настроим папки синхронизации, но по сути к чему тут будут сводиться сами бекапы? К тому, чтобы копировать нужные мне данные на сервере в папку синхронизации? Ок, даже если по крону, не лаконичнее ли написать скрипт на баше, который будет сам делать бекапы всего, архивировать и т.д. и отправлять на диск, при этом не требуется установка никаких утилит. Не знаю, мне кажется, что этот способ довольно удобен, может быть кто-то предложит что-то лучше. А что касается того, что предложили вы, если я правильно все понял, как-то не особо удобно/хорошо и т.д.
hrvasiliy:
Шаг 1 - подключить Ядиск
Шаг 2 - настроить бэкапы, а как - решать Вам
Шаг 3 - класть их на Ядиск
Таким образом, если Вы не знаете как хотите сделать бэкап, то и гуглите в этом направлении или задавайте конкретный вопрос с рассказом что и как работает
mureevms: В принципе, это как вариант, может вы и правы, попробовать стоит. А что касается самих настроек и утилит VDS, тут как быть? Имею в виду, что нужно копировать и как восстанавливаться?
hrvasiliy: Понимаете, аббревиатура VDS говорит только о типе снимаемого Вами сервера. Что там внутри не известно и поэтому сказать что-то конкретно сложно. Поэтому еще раз говорю, гуглите в этом направлении или задавайте конкретный вопрос с рассказом что и как работает
mureevms: Я скинул статью, где не требуется никакая установка, но скрипт почему-то не работает. По поводу VDS: Ubuntu Server 14.04, LAMP, JailKit - все.
hrvasiliy: просмотрел более внимательно предлагаемый скрипт. Мое мнение - автор страдает фигней и мало знаком с линуксом. Он вводит совершенно ненужные сущности и усложняет задачу.
Пара вопросов:
Операционную систему планируете бэкапить или только сайты с базами?
Если забэкапите сайты и их базы, то сможете все восстановить на чистой системе?
Какая CMS используется на сайтах (в бэкапу вопрос не относится, но к восстановлению может, если это Wordpress)?
mureevms:
1. Хотелось бы бэкапить все (систему, настройки, базы данных, папку со всеми сайтами), чтобы в случае чего я смог полностью восстановиться.
2. Проблемы с восстановлениям могут быть связаны с настройками апача, ну по сути, тут решаемо все. Восстановление из дампов БД так же должно пройти без проблем, там вроде как ничего сложного (опять же, все в теории, восстанавливался всего пару раз).
3. Движков не использую.
mureevms: Извините, а фраза "Теперь ясно :)" сказана с какой-то насмешкой? Вроде глупостей не говорил, вот и задумался.
Предисловие.
Вы должны смонтировать Ядиск как описано в этой статье в каталог /mnt/yadisk, туда будут копироваться все бэкапы
Для бэкапа всей системы лучше пользоваться инструментами которые предлагает хостер. Если таких нет или планируется переезд всей системы, то используйте п.1.
Специально оставляю одну копию каждого бэкапа на VDS для удобства восстановления какого-либо файла.
Прокомментирую только первый файл, остальные сделаны по подобию.
Каталоги в /home/backup/. и /mnt/yadisk/. должны быть созданы.
Скрипт бэкапа разбит на 4 штуки намеренно для удобства использования и запуска по крону с разными временными интервалами, что и надо будет сделать отдельно.
Так же, советую предварительно перед бэкапом проверять смонтирован ли Ядиск, иначе место может внезапно закончится на сервере. Если интересно, то потом дам ссылку как это сделать.
1. Бэкап системы осуществляется при помощи команды tar
Файл system_backup.sh:
2. Бэкап конфигов осуществляется так же при помощи команды tar (при текущих исходных данных все конфиги лежат в /etc)
Файл etc_backup.sh:
3. Бэкап сайтов осуществляется аналогично (предполагаю, что они лежат в /var/www/)
Файл www_backup.sh:
4. Бэкап MySQL осуществляется при помощи команды mysqldump
Файл mysql_backup.sh
Восстановление
Восстановление сайтов и конфигов осуществляется простым копированием в место назначения.
Восстановление баз:
Восстановление системы более сложный процесс, но суть сводится к одному - сделать чистую установку аналогичной ОС, загрузится с LIVE CD, подмонтировать Ядиск и распаковать архив в root директорию (root директорией называют корень файловой системы - / ), за исключением каталога /boot
ОБЯЗАТЕЛЬНО заранее проделать восстановление на отдельной виртуалке.
Вместо послесловия
Такой бэкап, как говорится, и палкой не убить. Единственное, что надо делать - время от времени руками проверять архивы бэкапов на читаемость и прохождению нормального разархивирования. К сожалению, архивы бывают битыми.
В прошлой статье из цикла я рассказывал, как настроить автоматическое архивирование ценных для вас директорий в специально отведенную для этого папку. Хотя такое решение вполне может однажды спасти вас от появления нескольких седых волос, оно далеко не совершенно. Стоит выйти из строя жесткому диску — и восстановить данные будет очень и очень непросто.
Сегодняшняя статья посвящена тому, как настроить создание и отправку резервных копий в удаленное хранилище, в качестве которого я буду использовать Яндекс.Диск. Помимо повышенной надежности такой подход хорош еще и тем, что позволяет получать доступ к своим данным откуда угодно.
В процессе мы познакомимся с новыми типами юнитов systemd: .timer, .mount и .automount.
1. Установка WebDAV и подготовка папки для автомонтирования.
Для начала установим пакет davfs2:
В процессе разрешаем непривилегированным пользователям монтирование.
Поскольку для доступа к содержимому Яндекс.Диска нам небходимо пройти аутентификацию, добавим URL, логин и пароль от своей учетной записи в Яндексе в специальный файл, остальное WebDAV сделает за нас:
В конец открывшегося файла добавляем строку следующего содержания:
Если пароль содержит пробелы, символы решетки, двойных кавычек или обратный слеш (\), его необходимо заключить в двойные кавычки. Подробнее об этом можно прочитать в самом редактируемом файле.
Не только Яндекс.Диск поддерживает WebDAV. Вы можете использовать похожим образом многие другие хранилища, в том числе Dropbox.
Создадим папку, в которую будем монтировать нашу удаленную ФС и тут же передадим ее текущему пользователю:
Здесь и далее вместо переменной $USER можете использовать имя своего пользователя либо просто скопировать и ввести команды как есть. Во втором случае имя текущего пользователя будет подставлено автоматически.
На всякий случай проверим результат:
Если все прошло успешно, вы увидите, что папка создалась и принадлежит вашему пользователю.
2. Пишем юниты .mount и .automount.
Юниты .mount и .automount описывают точки монтирования, а также условия, при которых те должны быть смонтированы. Их название в обязательном порядке должно отражать путь к самой точке монтирования, причем символ «/» заменяется на «-», а другие специальные символы… словом, лучше используйте обычную латиницу в названиях. Так, например, для точки монтирования /media/valera/YaDisk нам понадобятся юниты c названиями media-valera-YaDisk.mount и media-valera-YaDisk.automount.
Создаем эти два файла там, где и положено находиться пользовательским юнитам в Ubuntu 16.04, открывая их любым удобным текстовым редактором:
В открывшееся окно редактора помещаем следующее:
Тем же способом открываем /etc/systemd/system/media-$USER-YaDisk.automount и добавляем в него строки, приведенные ниже:
Не забудьте оба раза сохранить содержимое, иначе файлы просто не будут созданы.
Чтобы не перезагружать систему, скажем systemd перечитать юниты:
Теперь активируем и добавляем в автозагрузку наш .automount юнит:
Юнит .mount включать и запускать нет необходимости.
3. Создаем скрипт, выполняющий резервное копирование и юниты .service и .timer, которые будут его запускать.
Откроем пока еще не существующий файл скрипта командой:
вставим следующий код в текстовый редактор и сохраним.
«/путь/к/папке» нужно заменить на настоящий путь к директории, резервные копии которой вы собираетесь создавать.
Создаем юнит yadisk_backup.service с таким содержимым:
и юнит yadisk_backup.timer:
Как вы уже знаете, поместить оба файла нужно в /etc/systemd/system. Перечитываем юниты, запускаем и включаем таймер:
Первая строка в разделе [Timer] будет запускать таймер по прошествии суток с момента последней активации. Вторая строка запускает его через 60 секунд после загрузки.
Обратите внимание!
Юнит .timer управляет запуском юнита .service. Названия этих юнитов (части названия до точки) должны совпадать, иначе система просто не поймет, что именно должен запускать наш таймер. Если по каким-то причинам названия все же разные, полное имя файла .service можно задать и внутри таймера.
Бонус: доступ к Яндекс.Диску через файловый менеджер.
Во-первых, поздравляю тех, кто дочитал до этого места. Вы настоящие герои. Во-вторых, хочу обратить ваше внимание на полезный побочный эффект, возникающий в результате выполнения первых двух пунктов. Вот он:
Яндекс.Диск монтируется в отведенную ему директорию, после чего с ним можно работать через файловый менеджер так же, как вы делаете это с локальными папками. Удобнее, чем пользоваться веб-интерфейсом или различными утилитами, не правда ли?
Если резервное копирование вам не нужно, а требуется лишь удобный доступ к своему облачному хранилищу, достаточно будет выполнить первые два пункта статьи.
Admin 15.05.2017 , обновлено: 18.05.2020 CentOS, Linux, VPS
Создаём резервное копирование сервера на Яндекс Диск, по протоколу WebDAV, для операционной системы CentOS 7 x64.
Резервную копию на Яндекс Диск можно выполнить двумя способами. В предыдущей статье уже описывалось как синхронизировать backup папки на Яндекс диск с помощью консольного клиента. В этой статье будет рассказано, как делать резервные копии и перемещать их на Яндекс Диск.
Ошибка can’t write entry into mtab
После монтированная часто возникает такая надпись:
Ошибка не влияет на работу. Несмотря на это предупреждение всё прекрасно работает.
Подключение по сертификату
Более подробно о том как настраивать механизм подключения по сертификаты можете найти в статье RSA или авторизация SSH по ключу.
Скопируем на подключаемый ресурс необходимую часть ключа:
После успешного выполнения пробуем подключиться:
В случае успеха идём дальше.
Для безопасности можно создать пользователя на ресурсе откуда забираете данные и ограничить его только в папке откуда забираем резервные копии.
Резервное копирования на Google Диск.
С резервным копированием в Google Диск в се вышло не так просто как с OneDrive, хотя сама настройка довольно простая. Основная проблема возникла с удалением старых бэкапов с Google Drive, так как на сервер не монтируется директория хранилища. Но после долгого изучения справки drive help, удалось модернизировать наш уже ранее используемый скрипт.
Остальные шаги в скрипте я не расписывал, так как они повторяются с предыдущими.
Запустив скрипт, он выполнился:
С веб-интерфейса его так же видно, как и с консоли:
Таким образом мы получаем скрипт, который выполняет проверку на наличие старых бэкапов в облаке Google Диск, удаляет их если они попадают под требования, после чего создает резервную копию сайта и отправляет ее в это же облако.
Backup данных на OneDrive изLinux CentOS
Мы будем выполнять резервное копирование сайта и базы данных, а также выполнять проверку на «возраст» бэкапа (удалять бэкапы недельной давности) и отправлять на почту отчет с полной информацией выполнения скрипта. Собственно, сам bash скрипт:
Предварительно перед написанием статьи, я создал уже несколько бэкапов, чтобы можно было продемонстрировать, что скрипт работает корректно (удаляет старые бэкапы и закачивает новые).
Я запустил 3 раза вручную. Были созданы несколько резервных копий, после чего они все успешно были отправлены в облако:
ls -la /root/OneDrive/backup/
Проверяем облако, все три архива с резервными копиями здесь:
Следующим шагом, я удалил созданные резервные копии с директории на сервере и снова запустил скрипт. Вывод содержимого директории на сервере:
ls -la /root/OneDrive/backup/
Пройдя в веб-интерфейс OneDrive я увидел, что резервные копии удалили и оттуда, автоматически.
Так же после выполнения скрипта, мне пришло письмо на почту:
Вот и все, на этом резервное копирование на OneDrive окончено.
Читайте также: