Вопросы Теги

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

Я так не думаю, но вы можете легко изменить сценарии preinst / postinst, чтобы проверить, установлен ли пакет в первый раз и принять стандартное действие.

Может быть что-то вроде этого,

в preinst. 

if not is_package_istalled():
    export MY_PACKAGE_FIRST_INSTALL

в postinst, 

if MY_PACKAGE_FIRST_INSTALL:
    Do First Install Setup

Edit

Хмм, возможно, вы можете просто проверить все это прямо в postinst, потому что я думаю, что dpkg не установил статус пакета как установленный до выполнения postinst, но я не уверен. Таким образом, вышесказанное могло бы прийти,

в postinst, 

if not is_package_istalled():
    Do First Install Setup

Где, is_package_installed, вы можете определить статус установки. Может быть что-то вроде «dpkg --status packagename»

ИЛИ

Почему бы просто не проверить, действительно ли изменения, которые вы хотите сделать, уже существуют и продолжаются, если они не являются. [ ! d10]

6
задан 2 May 2018 в 13:30

12 ответов

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

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

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

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

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

Вы можете настроить временную метку с помощью параметра dateformat, см. Logrotate (8).

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

4
ответ дан 22 May 2018 в 11:14
  • 1
    +1 для идеи logratate. К сожалению, время выполнения заданий cron.daily немного сложнее, потому что cron и anacron каким-то образом взаимодействуют и ведут себя по-разному в зависимости от того, установлен ли anacron (рабочий стол) или нет (сервер). См. здесь , например. Но в любом случае: я очень хорошо поработал с cron.daily, потому что моя система не все время, а cron.daily просто говорит: запускает ее один раз в день, если компьютер встает . Вы можете изменить порядок выполнения, переименовав файлы в /etc/cron.daily. – PerlDuck 1 May 2018 в 17:31
  • 2
    @PerlDuck да, это просто, но не очень надежный. Но это то, что вы получаете, когда не используете надлежащее программное обеспечение для резервного копирования :) – Sebastian Stark 1 May 2018 в 19:12
  • 3
    Честно говоря, я предпочитаю свое инкрементное rsync решение (и ваш подход) по любому правильному программному обеспечению резервного копирования , потому что они, как правило, усложняют ситуацию. Часто проприетарный или, по крайней мере, запутанный формат, файлы, скрытые где-то в архиве или несколько архивов со странными именами, такими как abf42df82de92a.001.gz.gpg и неясная база данных, которая сообщает, где находится файл. Невозможно восстановить файлы, не устанавливая снова резервное программное обеспечение , чтобы восстановить их. Таким образом, мне нравится ваша комбинация tar.gz плюс logrotate. – PerlDuck 1 May 2018 в 19:25
  • 4
    Вы можете запустить резервную копию как скрипт pre-or postrotate в logrotate, но тогда это не будет минимальным решением для проблемы с OPs. – Sebastian Stark 2 May 2018 в 08:12
  • 5
    Также я обнаружил, что это самая большая проблема в «roll-your-own-backup». сценарии в моем опыте - обработка ошибок и непредвиденных ситуаций (полный диск, пустые архивы, ошибки, протоколирование, уведомления) – Sebastian Stark 2 May 2018 в 08:14

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

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

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

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

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

Вы можете настроить временную метку с помощью параметра dateformat, см. Logrotate (8).

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

4
ответ дан 17 July 2018 в 16:08

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

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

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

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

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

Вы можете настроить временную метку с помощью параметра dateformat, см. Logrotate (8).

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

4
ответ дан 23 July 2018 в 17:02

Это (вариант) используемого сценария (/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 для локальной копии файлов из моего домашнего каталога в резервную папку, [ f5] в моем случае. Ниже этого целевого каталога создается каталог с текущей временной меткой, например. /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/, чтобы указать на предыдущую резервную копию.

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

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

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

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

/tmp/my-backups/2018-04-29T... /tmp/my-backups/2018-04-30T... /tmp/my-backups/2018-05-01T...

и удалить второй каталог, то вы просто потеряете жесткие ссылки [!d5 ] этого дня, но файлы все еще находятся в 1-м или 3-м каталоге (или и то, и том же).

Я положил cronjob в /etc/cron.daily, который гласит: 

#!/bin/sh
/usr/bin/systemd-cat -t backupscript -p info /home/pduck/bup.sh
15] Назовите этот файл backup или что-то, chmod +x, но опустите суффикс .sh (тогда он не будет запущен). Из-за /usr/bin/systemd-cat -t backupscript -p info вы можете наблюдать прогресс через journalctl -t backupscript.

Обратите внимание, что это решение rsync требует, чтобы целевой каталог находился в файловой системе ext4 из-за жестких ссылок.

5
ответ дан 22 May 2018 в 11:14
  • 1
    Я рекомендую использовать время UTC (date -u), так как местное время может измениться, особенно если вы находитесь в регионе, используя летнее время. Также date -u -Is напечатает дату в формате ISO 8601. – pim 1 May 2018 в 16:52
  • 2
    @pim Хороший улов, особенно UTC. И да, мы можем играть с форматом времени, опустить секунды или время в целом. Это зависит от того, насколько вы точно это хотите. Мне лично не нравится суффикс TZ (+02:00 в моем немецком деле). Важно только то, что лексический порядок должен отражать хронологический порядок, чтобы упростить выбор предыдущего каталога. И да, мы не должны разбирать вывод ls . – PerlDuck 1 May 2018 в 17:01
  • 3
    Я применил этот хороший сценарий для своих нужд и добавил параметр exclude (также добавил некоторые кавычки): paste.ubuntu.com/p/NgfXMPy8pK – pa4080 1 May 2018 в 20:09
  • 4
    @ pa4080 Прохладный, я чувствую честь. :-) Есть больше каталогов, которые вы можете исключить, например. ~/.cache и, вероятно, некоторые другие дотдиры. – PerlDuck 1 May 2018 в 20:13
  • 5
    Только для записей. Я создал репозиторий GitHub, где доступны мои резервные сценарии: github.com/pa4080/simple-backup-solutions – pa4080 8 May 2018 в 10:29

С небольшим редактированием вашей команды 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 дней. НТН

3
ответ дан 22 May 2018 в 11:14

Вот часть решения из моего ежедневного сценария резервного копирования, который вызывается cron: Backup 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 ГБ), поэтому мои ежедневные резервные копии могут выполняться некоторое время, прежде чем мне удастся удалить файлы. Но вместо философии «все старше, чем ххх» я буду использовать стратегию дедушки-отца-сына, описанную здесь: Резервное копирование Linux, скриптов и документов в Gmail . Вкратце:

включает целевые файлы /home/me/*, но пропускает 1 ГБ файлов /home/, важных для вас, используемых FireFox, Chrome и другими приложениями, которые мне не интересны при резервном копировании. [ ! d3] Воскресные резервные копии (еженедельные резервные копии), очищенные через 8 недель , включают важные файлы для меня, но неважны для вас в /etc/cron*, /etc/system*, /lib/systemd/system-sleep, /etc/rc.local, /boot/grub, /usr/share/plymouth , /etc/apt/trusted.gpg и т. д. Резервные копии в течение последнего года (Ежегодные резервные копии) сохраняются навсегда

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

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

[d18 ] Вкратце: 

DAYS_TO_KEEP=60
find $BACKUP_DIR -maxdepth 1 -mtime +"$DAYS_TO_KEEP" -exec rm -rf {} \;
3
ответ дан 22 May 2018 в 11:14

С небольшим редактированием вашей команды 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 дней. НТН

3
ответ дан 17 July 2018 в 16:08

Это (вариант) используемого сценария (/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 не копирует файлы, которые не изменились по сравнению с файлами в каталоге link-dest. Вместо этого он создает жесткие ссылки между текущими и предыдущими файлами.

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

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

/tmp/my-backups/2018-04-29T... /tmp/my-backups/2018-04-30T... /tmp/my-backups/2018-05-01T...

и удалить второй каталог, то вы просто потеряете жесткие ссылки этого дня, но файлы все еще находятся в 1-м или 3-м каталоге (или оба).

Я положил cronjob в /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 из-за жестких ссылок.

5
ответ дан 17 July 2018 в 16:08

Вот часть решения из моего ежедневного сценария резервного копирования, который вызывается cron: Backup 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 ГБ), поэтому мои ежедневные резервные копии могут выполняться некоторое время, прежде чем мне удастся удалить файлы. Но вместо философии «все старше, чем ххх» я буду использовать стратегию дедушки-отца-сына, описанную здесь: Резервное копирование Linux, скриптов и документов в Gmail . Вкратце:

включает целевые файлы /home/me/*, но пропускает 1 ГБ файлов /home/, важных для вас, используемых FireFox, Chrome и другими приложениями, которые мне не интересны при резервном копировании. [ ! d3] Воскресные резервные копии (еженедельные резервные копии), очищенные через 8 недель , включают важные файлы для меня, но неважны для вас в /etc/cron*, /etc/system*, /lib/systemd/system-sleep, /etc/rc.local, /boot/grub, /usr/share/plymouth , /etc/apt/trusted.gpg и т. д. Резервные копии в течение последнего года (Ежегодные резервные копии) сохраняются навсегда

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

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

Вкратце:

DAYS_TO_KEEP=60 find $BACKUP_DIR -maxdepth 1 -mtime +"$DAYS_TO_KEEP" -exec rm -rf {} \;
3
ответ дан 17 July 2018 в 16:08

С небольшим редактированием вашей команды 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 дней. НТН

3
ответ дан 23 July 2018 в 17:02

Это (вариант) используемого сценария (/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 не копирует файлы, которые не изменились по сравнению с файлами в каталоге link-dest. Вместо этого он создает жесткие ссылки между текущими и предыдущими файлами.

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

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

/tmp/my-backups/2018-04-29T... /tmp/my-backups/2018-04-30T... /tmp/my-backups/2018-05-01T...

и удалить второй каталог, то вы просто потеряете жесткие ссылки этого дня, но файлы все еще находятся в 1-м или 3-м каталоге (или оба).

Я положил cronjob в /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 из-за жестких ссылок.

5
ответ дан 23 July 2018 в 17:02
  • 1
    Я рекомендую использовать время UTC (date -u), так как местное время может измениться, особенно если вы находитесь в регионе, используя летнее время. Также date -u -Is напечатает дату в формате ISO 8601. – pim 1 May 2018 в 16:52
  • 2
    @pim Хороший улов, особенно UTC. И да, мы можем играть с форматом времени, опустить секунды или время в целом. Это зависит от того, насколько вы точно это хотите. Мне лично не нравится суффикс TZ (+02:00 в моем немецком деле). Важно только то, что лексический порядок должен отражать хронологический порядок, чтобы упростить выбор предыдущего каталога. И да, мы не должны разбирать вывод ls . – PerlDuck 1 May 2018 в 17:01
  • 3
    Я применил этот хороший сценарий для своих нужд и добавил параметр exclude (также добавил некоторые кавычки): paste.ubuntu.com/p/NgfXMPy8pK – pa4080 1 May 2018 в 20:09
  • 4
    @ pa4080 Прохладный, я чувствую честь. :-) Есть больше каталогов, которые вы можете исключить, например. ~/.cache и, вероятно, некоторые другие дотдиры. – PerlDuck 1 May 2018 в 20:13
  • 5
    Только для записей. Я создал репозиторий GitHub, где доступны мои резервные сценарии: github.com/pa4080/simple-backup-solutions – pa4080 8 May 2018 в 10:29

Вот часть решения из моего ежедневного сценария резервного копирования, который вызывается cron: Backup 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 ГБ), поэтому мои ежедневные резервные копии могут выполняться некоторое время, прежде чем мне удастся удалить файлы. Но вместо философии «все старше, чем ххх» я буду использовать стратегию дедушки-отца-сына, описанную здесь: Резервное копирование Linux, скриптов и документов в Gmail . Вкратце:

включает целевые файлы /home/me/*, но пропускает 1 ГБ файлов /home/, важных для вас, используемых FireFox, Chrome и другими приложениями, которые мне не интересны при резервном копировании. [ ! d3] Воскресные резервные копии (еженедельные резервные копии), очищенные через 8 недель , включают важные файлы для меня, но неважны для вас в /etc/cron*, /etc/system*, /lib/systemd/system-sleep, /etc/rc.local, /boot/grub, /usr/share/plymouth , /etc/apt/trusted.gpg и т. д. Резервные копии в течение последнего года (Ежегодные резервные копии) сохраняются навсегда

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

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

Вкратце:

DAYS_TO_KEEP=60 find $BACKUP_DIR -maxdepth 1 -mtime +"$DAYS_TO_KEEP" -exec rm -rf {} \;
3
ответ дан 23 July 2018 в 17:02

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

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