Простое решение для резервного копирования

Question 1

Я ищу очень простой резервный сценарий/пакет для каталога на моем сервере Ubuntu. В настоящее время я использую cronjob как это:

0 5 * * 1 sudo tar -Pzcf /var/backups/home.tgz /home/

Но я хочу решение, которое добавляет метку времени к имени файла и не переопределяет старые резервные копии. Конечно, это будет медленно лавинно рассылать мой диск, таким образом, старые резервные копии (например, более старый, чем 2 месяца) должны будут быть удалены автоматически.

С наилучшими пожеланиями, Dennis

ОБНОВЛЕНИЕ: я решил дать щедрость logrotate- решение из-за это - простота. Но большое спасибо всем другим отвечающим сторонам, также!

Question 2

Простое решение с использованием logrotate

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

Для этого поместите следующее в файл с именем /etc/logrotate.d / backup-home :

/var/backups/home.tgz {
    weekly
    rotate 8
    nocompress
    dateext
}

С этого момента каждый раз, когда запускается logrotate (а обычно он выполняется каждый день в 6:25 утра), он проверяет, подходит ли он для ротации, и, если да, переименовывает ваш home.tgz в другой файл с добавленной меткой времени. В нем будет храниться 8 копий, так что у вас будет примерно два месяца истории.

Вы можете настроить метку времени, используя параметр dateformat , см. logrotate (8) .

] Поскольку ваше задание резервного копирования запускается в 5 часов утра, а logrotate - в 6:25 утра, вы должны убедиться, что резервное копирование tar выполняется в течение 1 часа и 25 минут (я думаю, что в любом случае это будет намного быстрее).

Question 3

Question 4

Это (вариант) скрипта, который я использую ( /home/pduck/bup.sh ):

#!/usr/bin/env bash

src_dir=/home/pduck
tgt_dir=/tmp/my-backups
mkdir -p $tgt_dir

# current backup directory, e.g. "2017-04-29T13:04:50";
now=$(date +%FT%H:%M:%S) 

# previous backup directory
prev=$(ls $tgt_dir | grep -e '^....-..-..T..:..:..$' | tail -1); 

if [ -z "$prev" ]; then
    # initial backup
    rsync -av --delete $src_dir $tgt_dir/$now/
else
    # incremental backup
    rsync -av --delete --link-dest=$tgt_dir/$prev/ $src_dir $tgt_dir/$now/
fi

exit 0;

Он использует rsync для локального копирования файлов из моего домашнего каталога в место резервного копирования, / tmp / my-backups в моем случае. Ниже этого целевого каталога создается каталог с текущей меткой времени, например / tmp / my-backups / 2018-04-29T12: 49: 42 и ниже этого каталога размещается резервная копия того дня.

Когда сценарий запускается еще раз, он замечает, что там уже является каталогом / tmp / my-backups / 2018-04-29T12: 49: 42 (он выбирает «последний» каталог, соответствующий шаблону временной метки). Затем он выполняет команду rsync , но на этот раз с переключателем - link-dest = / tmp / my-backups / 2018-04-29T12: 49: 42 / , чтобы указать на предыдущая резервная копия.

Это фактическая точка создания инкрементных резервных копий:

С - link-dest =… rsync не копирует файлы, которые не были изменены по сравнению с файлами в ссылке - каталог dest. Вместо этого он просто создает жестких ссылок между текущим и предыдущим файлами.

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

Уборка также очень проста: просто rm -rf каталог с отметками времени, который вы не хотите оставлять. Это не приведет к удалению старых, новых или неизмененных файлов, просто удалит (уменьшит) жесткие ссылки. Например, если у вас три поколения:

/ tmp / my-backups / 2018-04-29T ...
/ tmp / my-backups / 2018-04-30T ...
/ tmp /my-backups/2018-05-01T…………………………………………………………………………………………………………………………………………………………………………………………………… (или оба). Я поместил задание cron в /etc/cron.daily , которое гласит: #!/bin/sh /usr/bin/systemd-cat -t backupscript -p info /home/pduck/bup.sh Назовите этот файл backup или что-то в этом роде, chmod + x это, но опускает суффикс .sh (тогда он не будет запущен). Благодаря / usr / bin / systemd-cat -t backupscript -p info вы можете наблюдать за прогрессом с помощью journalctl -t backupscript . Обратите внимание, что это rsync решение требует, чтобы целевой каталог находился в файловой системе ext4 из-за жестких ссылок.

Question 5

Немного отредактировав команду cron, вы можете добавить метку времени к имени файла:

0 5 * * 1 sudo tar -Pzcf /var/backups/home_$(date "+%Y-%m-%d_%H-%M-%S").tgz /home/

Что касается очистки, я нашел отличный однострочный сценарий здесь , который я адаптировал для вашего случая:

find . -type f -name 'home_*.tgz' -exec sh -c 'bcp="${1%_*}"; bcp="${bcp#*_}"; [ "$bcp" "<" "$(date +%F -d "60 days ago")" ] && rm "$1"' 0 {} \;

Вы можете добавить указанную выше команду к другому заданию cron, и оно удалит резервные копии старше 60 дней. HTH

Question 6

Вот часть решения из моего ежедневного сценария резервного копирования, который вызывается cron: Резервное копирование конфигурации Linux, сценариев и документов в Gmail . Полный сценарий подходит, потому что:

он включает целевые / home / me / * файлы, но пропускает 1 ГБ из / home / важных для вас файлов, используемых FireFox, Chrome и другие приложения, резервное копирование которых мне неинтересно.
оно включает важные для меня файлы, но неважные для вас, в / etc / cron * , / etc / system * , / lib / systemd / system-sleep , /etc/rc.local , / boot / grub , / usr / share / plymouth , /etc/apt/trusted.gpg и т. Д.
каждое утро он отправляет резервную копию по электронной почте на мою учетную запись gmail.com для резервного копирования за пределами сайта. Ваши резервные копии хранятся не только на сайте, но и на том же компьютере.

Вот соответствующий сценарий, части которого вы можете адаптировать:

#!/bin/sh
#
# NAME: daily-backup
# DESC: A .tar backup file is created, emailed and removed.
# DATE: Nov 25, 2017.
# CALL: WSL or Ubuntu calls from /etc/cron.daily/daily-backup
# PARM: No parameters but /etc/ssmtp/ssmtp.conf must be setup

# NOTE: Backup file name contains machine name + Distro
#       Same script for user with multiple dual boot laptops
#       Single machine should remove $HOSTNAME from name
#       Single distribution should remove $Distro

sleep 30 # Wait 30 seconds after boot

# Running under WSL (Windows Subsystem for Ubuntu)?
if cat /proc/version | grep Microsoft; then
    Distro="WSL"
else
    Distro="Ubuntu"
fi

today=$( date +%Y-%m-%d-%A )
/mnt/e/bin/daily-backup.sh Daily-$(hostname)-$Distro-backup-$today

Мой gmail.com заполнен только на 35% (из 15 ГБ) поэтому мои ежедневные резервные копии могут работать еще некоторое время, прежде чем мне придется удалять файлы. Но вместо философии «все старше ххх» я буду использовать стратегию дед-отец-сын, как описано здесь: Нужно ли вести учет моих резервных копий? . Вкратце:

с понедельника по воскресенье (ежедневные резервные копии), которые удаляются через 14 дней
воскресные резервные копии (еженедельные резервные копии) удаляются через 8 недель
Резервные копии в последний день месяца (ежемесячные резервные копии) удаляются через 18 месяцев
Резервные копии последнего дня года (ежегодные резервные копии) хранятся вечно

Мой процесс очистки будет осложнен тем, что мне придется изучить Python и установить библиотеку Python для управления папками Gmail.

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

В итоге:

DAYS_TO_KEEP=60
find $BACKUP_DIR -maxdepth 1 -mtime +"$DAYS_TO_KEEP" -exec rm -rf {} \;

Sebastian Stark · Accepted Answer · 23 November 2019 в 07:20

Простое решение с использованием logrotate

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

Для этого поместите следующее в файл с именем /etc/logrotate.d / backup-home :

/var/backups/home.tgz {
    weekly
    rotate 8
    nocompress
    dateext
}

С этого момента каждый раз, когда запускается logrotate (а обычно он выполняется каждый день в 6:25 утра), он проверяет, подходит ли он для ротации, и, если да, переименовывает ваш home.tgz в другой файл с добавленной меткой времени. В нем будет храниться 8 копий, так что у вас будет примерно два месяца истории.

Вы можете настроить метку времени, используя параметр dateformat , см. logrotate (8) .

] Поскольку ваше задание резервного копирования запускается в 5 часов утра, а logrotate - в 6:25 утра, вы должны убедиться, что резервное копирование tar выполняется в течение 1 часа и 25 минут (я думаю, что в любом случае это будет намного быстрее).

pa4080 · Answer 2 · 23 November 2019 в 07:20

Это (вариант) скрипта, который я использую ( /home/pduck/bup.sh ):

#!/usr/bin/env bash

src_dir=/home/pduck
tgt_dir=/tmp/my-backups
mkdir -p $tgt_dir

# current backup directory, e.g. "2017-04-29T13:04:50";
now=$(date +%FT%H:%M:%S) 

# previous backup directory
prev=$(ls $tgt_dir | grep -e '^....-..-..T..:..:..$' | tail -1); 

if [ -z "$prev" ]; then
    # initial backup
    rsync -av --delete $src_dir $tgt_dir/$now/
else
    # incremental backup
    rsync -av --delete --link-dest=$tgt_dir/$prev/ $src_dir $tgt_dir/$now/
fi

exit 0;

Он использует rsync для локального копирования файлов из моего домашнего каталога в место резервного копирования, / tmp / my-backups в моем случае. Ниже этого целевого каталога создается каталог с текущей меткой времени, например / tmp / my-backups / 2018-04-29T12: 49: 42 и ниже этого каталога размещается резервная копия того дня.

Когда сценарий запускается еще раз, он замечает, что там уже является каталогом / tmp / my-backups / 2018-04-29T12: 49: 42 (он выбирает «последний» каталог, соответствующий шаблону временной метки). Затем он выполняет команду rsync , но на этот раз с переключателем - link-dest = / tmp / my-backups / 2018-04-29T12: 49: 42 / , чтобы указать на предыдущая резервная копия.

Это фактическая точка создания инкрементных резервных копий:

С - link-dest =… rsync не копирует файлы, которые не были изменены по сравнению с файлами в ссылке - каталог dest. Вместо этого он просто создает жестких ссылок между текущим и предыдущим файлами.

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

Уборка также очень проста: просто rm -rf каталог с отметками времени, который вы не хотите оставлять. Это не приведет к удалению старых, новых или неизмененных файлов, просто удалит (уменьшит) жесткие ссылки. Например, если у вас три поколения:

/ tmp / my-backups / 2018-04-29T ...
/ tmp / my-backups / 2018-04-30T ...
/ tmp /my-backups/2018-05-01T…………………………………………………………………………………………………………………………………………………………………………………………………… (или оба). Я поместил задание cron в /etc/cron.daily , которое гласит: #!/bin/sh /usr/bin/systemd-cat -t backupscript -p info /home/pduck/bup.sh Назовите этот файл backup или что-то в этом роде, chmod + x это, но опускает суффикс .sh (тогда он не будет запущен). Благодаря / usr / bin / systemd-cat -t backupscript -p info вы можете наблюдать за прогрессом с помощью journalctl -t backupscript . Обратите внимание, что это rsync решение требует, чтобы целевой каталог находился в файловой системе ext4 из-за жестких ссылок.

Eskander Bejaoui · Answer 3 · 23 November 2019 в 07:20

Немного отредактировав команду cron, вы можете добавить метку времени к имени файла:

0 5 * * 1 sudo tar -Pzcf /var/backups/home_$(date "+%Y-%m-%d_%H-%M-%S").tgz /home/

Что касается очистки, я нашел отличный однострочный сценарий здесь , который я адаптировал для вашего случая:

find . -type f -name 'home_*.tgz' -exec sh -c 'bcp="${1%_*}"; bcp="${bcp#*_}"; [ "$bcp" "<" "$(date +%F -d "60 days ago")" ] && rm "$1"' 0 {} \;

Вы можете добавить указанную выше команду к другому заданию cron, и оно удалит резервные копии старше 60 дней. HTH

WinEunuuchs2Unix · Answer 4 · 23 November 2019 в 07:20

Вот часть решения из моего ежедневного сценария резервного копирования, который вызывается cron: Резервное копирование конфигурации Linux, сценариев и документов в Gmail . Полный сценарий подходит, потому что:

он включает целевые / home / me / * файлы, но пропускает 1 ГБ из / home / важных для вас файлов, используемых FireFox, Chrome и другие приложения, резервное копирование которых мне неинтересно.
оно включает важные для меня файлы, но неважные для вас, в / etc / cron * , / etc / system * , / lib / systemd / system-sleep , /etc/rc.local , / boot / grub , / usr / share / plymouth , /etc/apt/trusted.gpg и т. Д.
каждое утро он отправляет резервную копию по электронной почте на мою учетную запись gmail.com для резервного копирования за пределами сайта. Ваши резервные копии хранятся не только на сайте, но и на том же компьютере.

Вот соответствующий сценарий, части которого вы можете адаптировать:

#!/bin/sh
#
# NAME: daily-backup
# DESC: A .tar backup file is created, emailed and removed.
# DATE: Nov 25, 2017.
# CALL: WSL or Ubuntu calls from /etc/cron.daily/daily-backup
# PARM: No parameters but /etc/ssmtp/ssmtp.conf must be setup

# NOTE: Backup file name contains machine name + Distro
#       Same script for user with multiple dual boot laptops
#       Single machine should remove $HOSTNAME from name
#       Single distribution should remove $Distro

sleep 30 # Wait 30 seconds after boot

# Running under WSL (Windows Subsystem for Ubuntu)?
if cat /proc/version | grep Microsoft; then
    Distro="WSL"
else
    Distro="Ubuntu"
fi

today=$( date +%Y-%m-%d-%A )
/mnt/e/bin/daily-backup.sh Daily-$(hostname)-$Distro-backup-$today

Мой gmail.com заполнен только на 35% (из 15 ГБ) поэтому мои ежедневные резервные копии могут работать еще некоторое время, прежде чем мне придется удалять файлы. Но вместо философии «все старше ххх» я буду использовать стратегию дед-отец-сын, как описано здесь: Нужно ли вести учет моих резервных копий? . Вкратце:

с понедельника по воскресенье (ежедневные резервные копии), которые удаляются через 14 дней
воскресные резервные копии (еженедельные резервные копии) удаляются через 8 недель
Резервные копии в последний день месяца (ежемесячные резервные копии) удаляются через 18 месяцев
Резервные копии последнего дня года (ежегодные резервные копии) хранятся вечно

Мой процесс очистки будет осложнен тем, что мне придется изучить Python и установить библиотеку Python для управления папками Gmail.

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

В итоге:

DAYS_TO_KEEP=60
find $BACKUP_DIR -maxdepth 1 -mtime +"$DAYS_TO_KEEP" -exec rm -rf {} \;

Простое решение для резервного копирования

4 ответа

Простое решение с использованием logrotate

Другие вопросы по тегам:

Похожие вопросы: