Что произойдет, если rsnapshot / rdiff-backup будет прервано в середине передачи?

/run/lock раньше /var/lock.

Он должен быть очищен или воссоздан во время процесса загрузки, для Ubuntu Я не уверен, какой скрипт это делает.

Тем не менее, я знаю, что для LFS сценарий /etc/rc.d/init.d/cleanfs выполняет задание => http://www.linuxfromscratch.org/lfs/view/stable/scripts/apds12.html

Некоторая предыстория: [!d5 ]

/var/run => /run находится в файловой системе памяти (tmpfs), используемой для хранения временных системных или государственных файлов (например, PID, Unix-сокет и т. д.), которые НЕ требуют сохранения на перезагрузках. [ ! d6]

see => LFS

Чтобы вручную создать / установить

sudo mkdir -p /run
sudo chmod 755 /run
sudo mount -t tmpfs -o rw,noexec,nosuid,size=10%,mode=0755 tmpfs /run

BTW: некоторые не относящиеся к теме материалы о tmpfs VS ramfs

tmpfs сворачивается на диск, но ramfs НЕ имеет tmpfs с фиксированным размером (указанным), но ramfs НЕ (вы можете продолжать писать даже больше максимального размера)

20
задан 15 October 2010 в 05:35

18 ответов

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rdiff-backup немного сложнее, потому что его подпрограмма более поэтапно и варьируется в зависимости от использования опций sync_first и use_lazy_deletes.

Если вы используете sync_first, а rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выпрямить вещи. Если вы случайно запустили rsnapshot <backup level> в этой точке, последняя резервная точка останется незавершенной и будет проходить через вращения. Если вы не используете sync_first, вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов. Если вы не вручную повернете по часовой стрелке каждую точку резервного копирования, неполная точка резервного копирования будет проходить через вращения. В обоих случаях запуск rsnapshot <backup level> приведет к потере самой старой точки резервного копирования, если только use_lazy_deletes не активирована.

Обратите внимание, что sync_first и use_lazy_deletes стоят за счет использования большего количества дискового пространства.

Напоминание / отказ от ответственности: , но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного, прочитайте каждое слово руководства и протестируйте, протестируйте, проверьте все сами!

21
ответ дан 26 May 2018 в 01:05
  • 1
    Наглядное напоминание и хорошая практика, чтобы идти в ногу с такими «правильными методами», культуры, мы не хотим, чтобы Linux превращался в немой-потребительскую землю. Спасибо за примечание. – emf 15 October 2010 в 20:40
  • 2
    Таким образом, правильное понимание: наличие неполной резервной копии, переносимой посредством поворота " для rsnapshot будет две вещи: 1. Этот снимок будет неполным, если он будет возвращен в более позднюю точку 2. Любые снимки более высокого уровня будут еще полными , но не будут правильно возвращаться к предыдущему файлы с жесткой связью, которые были пропущены в неполном снимке. Это верно? – emf 15 October 2010 в 20:53

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rdiff-backup немного сложнее, потому что его подпрограмма более поэтапно и варьируется в зависимости от использования опций sync_first и use_lazy_deletes.

Если вы используете sync_first, а rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выпрямить вещи. Если вы случайно запустили rsnapshot <backup level> в этой точке, последняя резервная точка останется незавершенной и будет проходить через вращения. Если вы не используете sync_first, вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов. Если вы не вручную повернете по часовой стрелке каждую точку резервного копирования, неполная точка резервного копирования будет проходить через вращения. В обоих случаях запуск rsnapshot <backup level> приведет к потере самой старой точки резервного копирования, если только use_lazy_deletes не активирована.

Обратите внимание, что sync_first и use_lazy_deletes стоят за счет использования большего количества дискового пространства.

Напоминание / отказ от ответственности: , но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного, прочитайте каждое слово руководства и протестируйте, протестируйте, проверьте все сами!

22
ответ дан 25 July 2018 в 23:06

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rdiff-backup немного сложнее, потому что его подпрограмма более поэтапно и варьируется в зависимости от использования опций sync_first и use_lazy_deletes.

Если вы используете sync_first, а rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выпрямить вещи. Если вы случайно запустили rsnapshot <backup level> в этой точке, последняя резервная точка останется незавершенной и будет проходить через вращения. Если вы не используете sync_first, вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов. Если вы не вручную повернете по часовой стрелке каждую точку резервного копирования, неполная точка резервного копирования будет проходить через вращения. В обоих случаях запуск rsnapshot <backup level> приведет к потере самой старой точки резервного копирования, если только use_lazy_deletes не активирована.

Обратите внимание, что sync_first и use_lazy_deletes стоят за счет использования большего количества дискового пространства.

Напоминание / отказ от ответственности: , но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного, прочитайте каждое слово руководства и протестируйте, протестируйте, проверьте все сами!

22
ответ дан 27 July 2018 в 02:43

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rsnapshot немного сложнее, потому что его процедура более ступенчатая и варьируется в зависимости от использования опций sync_first и use_lazy_deletes .

  • Если вы используете sync_first и rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выправить ситуацию. Если вы случайно запустили rsnapshot & lt; backup level & gt; в этой точке, последняя точка резервного копирования останется неполной и будет перенесена через вращение.
  • Если вы не используете sync_first , вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов.
  • В обоих случаях запуск rsnapshot & lt; backup level & gt; приведет к созданию самой старой резервной копии point [[d]]

Обратите внимание, что sync_first и use_lazy_deletes стоят за вычетом стоимости use_lazy_deletes использования большего количества дискового пространства.


Напоминание / отказ от ответственности: это должно быть само собой разумеющимся, но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного , прочитайте каждое слово руководства и test, test, test все себя!

22
ответ дан 2 August 2018 в 04:26

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rsnapshot немного сложнее, потому что его процедура более ступенчатая и варьируется в зависимости от использования опций sync_first и use_lazy_deletes .

  • Если вы используете sync_first и rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выправить ситуацию. Если вы случайно запустили rsnapshot & lt; backup level & gt; в этой точке, последняя точка резервного копирования останется неполной и будет перенесена через вращение.
  • Если вы не используете sync_first , вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов.
  • В обоих случаях запуск rsnapshot & lt; backup level & gt; приведет к созданию самой старой резервной копии point [[d]]

Обратите внимание, что sync_first и use_lazy_deletes стоят за вычетом стоимости use_lazy_deletes использования большего количества дискового пространства.


Напоминание / отказ от ответственности: это должно быть само собой разумеющимся, но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного , прочитайте каждое слово руководства и test, test, test все себя!

22
ответ дан 4 August 2018 в 20:59

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rsnapshot немного сложнее, потому что его процедура более ступенчатая и варьируется в зависимости от использования опций sync_first и use_lazy_deletes .

  • Если вы используете sync_first и rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выправить ситуацию. Если вы случайно запустили rsnapshot & lt; backup level & gt; в этой точке, последняя точка резервного копирования останется неполной и будет перенесена через вращение.
  • Если вы не используете sync_first , вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов.
  • В обоих случаях запуск rsnapshot & lt; backup level & gt; приведет к созданию самой старой резервной копии point [[d]]

Обратите внимание, что sync_first и use_lazy_deletes стоят за вычетом стоимости use_lazy_deletes использования большего количества дискового пространства.


Напоминание / отказ от ответственности: это должно быть само собой разумеющимся, но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного , прочитайте каждое слово руководства и test, test, test все себя!

22
ответ дан 6 August 2018 в 04:31

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rsnapshot немного сложнее, потому что его процедура более ступенчатая и варьируется в зависимости от использования опций sync_first и use_lazy_deletes .

  • Если вы используете sync_first и rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выправить ситуацию. Если вы случайно запустили rsnapshot & lt; backup level & gt; в этой точке, последняя точка резервного копирования останется неполной и будет перенесена через вращение.
  • Если вы не используете sync_first , вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов.
  • В обоих случаях запуск rsnapshot & lt; backup level & gt; приведет к созданию самой старой резервной копии point [[d]]

Обратите внимание, что sync_first и use_lazy_deletes стоят за вычетом стоимости use_lazy_deletes использования большего количества дискового пространства.


Напоминание / отказ от ответственности: это должно быть само собой разумеющимся, но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного , прочитайте каждое слово руководства и test, test, test все себя!

22
ответ дан 7 August 2018 в 22:40

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rsnapshot немного сложнее, потому что его процедура более ступенчатая и варьируется в зависимости от использования опций sync_first и use_lazy_deletes .

  • Если вы используете sync_first и rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выправить ситуацию. Если вы случайно запустили rsnapshot & lt; backup level & gt; в этой точке, последняя точка резервного копирования останется неполной и будет перенесена через вращение.
  • Если вы не используете sync_first , вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов.
  • В обоих случаях запуск rsnapshot & lt; backup level & gt; приведет к созданию самой старой резервной копии point [[d]]

Обратите внимание, что sync_first и use_lazy_deletes стоят за вычетом стоимости use_lazy_deletes использования большего количества дискового пространства.


Напоминание / отказ от ответственности: это должно быть само собой разумеющимся, но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного , прочитайте каждое слово руководства и test, test, test все себя!

22
ответ дан 10 August 2018 в 10:46

Я понимаю, что ...

rdiff-backup будет обнаруживать неполное приращение при следующем запуске. Он удалит неполное приращение, так что место резервного копирования будет таким же, как если бы прерванная попытка резервного копирования никогда не запускалась.

rsnapshot немного сложнее, потому что его процедура более ступенчатая и варьируется в зависимости от использования опций sync_first и use_lazy_deletes .

  • Если вы используете sync_first и rsnapshot sync прерывается, вы можете просто запустить rsnapshot sync еще раз, чтобы выправить ситуацию. Если вы случайно запустили rsnapshot & lt; backup level & gt; в этой точке, последняя точка резервного копирования останется неполной и будет перенесена через вращение.
  • Если вы не используете sync_first , вы просто застряли с неполной точкой резервного копирования, которая представляет собой гибрид старой и новой версий файлов.
  • В обоих случаях запуск rsnapshot & lt; backup level & gt; приведет к созданию самой старой резервной копии point [[d]]

Обратите внимание, что sync_first и use_lazy_deletes стоят за вычетом стоимости use_lazy_deletes использования большего количества дискового пространства.


Напоминание / отказ от ответственности: это должно быть само собой разумеющимся, но никогда не слепо доверять другим советам в Интернете. Если вы планируете использовать rdiff-backup или rsnapshot для чего-то критически важного , прочитайте каждое слово руководства и test, test, test все себя!

22
ответ дан 13 August 2018 в 17:20
  • 1
    Наглядное напоминание и хорошая практика, чтобы идти в ногу с такими «правильными методами», культуры, мы не хотим, чтобы Linux превращался в немой-потребительскую землю. Спасибо за примечание. – emf 15 October 2010 в 20:40
  • 2
    Таким образом, правильное понимание: наличие неполной резервной копии, переносимой посредством поворота " для rsnapshot будет равно двум вещам: 1. Этот снимок будет неполным, если он будет возвращен на более позднюю точку 2. Любые снимки более высокого уровня будут по-прежнему завершены , но не будут правильно ссылаться на предыдущие файлы с жесткой связью, которые были пропущены в неполном снимке. Это верно? – emf 15 October 2010 в 20:53

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

rsync: write failed on "<path>": No space left on device (28) 

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

Удалить последний каталог (например, ежедневно). Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...); Возможный сценарий1 Запустите резервную копию как обычно (снова).

Автоматически

rsnapshot не имеет возможностей паузы / остановки и возобновления (за исключением ограниченного «пропущенного из-за плана отката» 2), поэтому мы должны использовать обертку для обработки этих функций

rsnapshot-once 2 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

работает без изменения конфиг rsnapshot, чтобы ежедневные, еженедельные и ежемесячные задачи запускаются только один раз в соответствующий период времени, с помощью отката отката резервной копии cron (nice для ноутбуков) (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последовательные каталоги переименовываются, например, ежедневно1. > daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резерве и вуаля, удачный день ^ _ ^ Более плавный и безопасный чем предыдущее исходное решение на основе rsnapshot.

Примечание: slm связал меня здесь из повторяющегося вопроса: полное назначение Rsnapshot - как безопасно повторить?

1
ответ дан 26 May 2018 в 01:05

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

rsync: write failed on "<path>": No space left on device (28)

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

Удалить последний каталог (например, ежедневно). Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...); Возможный сценарий1 Запустите резервную копию как обычно (снова).

Автоматически

rsnapshot не имеет возможностей паузы / остановки и возобновления (за исключением ограниченного «пропущенного из-за плана отката» 2), поэтому мы должны использовать обертку для обработки этих функций

rsnapshot-once 2 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

работает без изменения конфиг rsnapshot, чтобы ежедневные, еженедельные и ежемесячные задачи запускаются только один раз в соответствующий период времени, с помощью отката отката резервной копии cron (nice для ноутбуков) (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последовательные каталоги переименовываются, например, ежедневно1. > daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резерве и вуаля, удачный день ^ _ ^ Более плавный и безопасный чем предыдущее исходное решение на основе rsnapshot.

Примечание: slm связал меня здесь из повторяющегося вопроса: полное назначение Rsnapshot - как безопасно повторить?

1
ответ дан 25 July 2018 в 23:06

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

rsync: write failed on "<path>": No space left on device (28)

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

Удалить последний каталог (например, ежедневно). Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...); Возможный сценарий1 Запустите резервную копию как обычно (снова).

Автоматически

rsnapshot не имеет возможностей паузы / остановки и возобновления (за исключением ограниченного «пропущенного из-за плана отката» 2), поэтому мы должны использовать обертку для обработки этих функций

rsnapshot-once 2 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

работает без изменения конфиг rsnapshot, чтобы ежедневные, еженедельные и ежемесячные задачи запускаются только один раз в соответствующий период времени, с помощью отката отката резервной копии cron (nice для ноутбуков) (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последовательные каталоги переименовываются, например, ежедневно1. > daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резерве и вуаля, удачный день ^ _ ^ Более плавный и безопасный чем предыдущее исходное решение на основе rsnapshot.

Примечание: slm связал меня здесь из повторяющегося вопроса: полное назначение Rsnapshot - как безопасно повторить?

1
ответ дан 27 July 2018 в 02:43

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

  rsync: сбой записи в «& lt; path & gt;»: на устройстве нет места (28)  

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

  1. Удалить последний каталог (например, daily.0)
  2. Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...);

Автоматически

rsnapshot не имеет паузы / (кроме ограниченного «, пропущенного из-за плана отката » 2 ), поэтому мы должны использовать обертку для обработки этих функций.

rsnapshot-once 3 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

  • работает без изменения вашей конфиги rsnapshot
  • гарантируют, что ежедневные, еженедельные и ежемесячные задания выполняются только один раз в соответствующий период времени, через cron (приятно для ноутбуков)
  • откат неудачной резервной копии (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последующие каталоги переименовываются, например, ежедневно1. -> daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резервном копировании и вуаля, удачный день ^ _ ^ Более плавный и безопасный, чем мой предыдущий основанный на rsnapshot solu

Примечание: slm связал меня здесь из дублированного вопроса: Назначение Rsnapshot целиком - как безопасно повторить?

1
ответ дан 2 August 2018 в 04:26

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

  rsync: сбой записи в «& lt; path & gt;»: на устройстве нет места (28)  

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

  1. Удалить последний каталог (например, daily.0)
  2. Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...);

Автоматически

rsnapshot не имеет паузы / (кроме ограниченного «, пропущенного из-за плана отката » 2 ), поэтому мы должны использовать обертку для обработки этих функций.

rsnapshot-once 3 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

  • работает без изменения вашей конфиги rsnapshot
  • гарантируют, что ежедневные, еженедельные и ежемесячные задания выполняются только один раз в соответствующий период времени, через cron (приятно для ноутбуков)
  • откат неудачной резервной копии (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последующие каталоги переименовываются, например, ежедневно1. -> daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резервном копировании и вуаля, удачный день ^ _ ^ Более плавный и безопасный, чем мой предыдущий основанный на rsnapshot solu

Примечание: slm связал меня здесь из дублированного вопроса: Назначение Rsnapshot целиком - как безопасно повторить?

1
ответ дан 4 August 2018 в 20:59

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

  rsync: сбой записи в «& lt; path & gt;»: на устройстве нет места (28)  

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

  1. Удалить последний каталог (например, daily.0)
  2. Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...);

Автоматически

rsnapshot не имеет паузы / (кроме ограниченного «, пропущенного из-за плана отката » 2 ), поэтому мы должны использовать обертку для обработки этих функций.

rsnapshot-once 3 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

  • работает без изменения вашей конфиги rsnapshot
  • гарантируют, что ежедневные, еженедельные и ежемесячные задания выполняются только один раз в соответствующий период времени, через cron (приятно для ноутбуков)
  • откат неудачной резервной копии (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последующие каталоги переименовываются, например, ежедневно1. -> daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резервном копировании и вуаля, удачный день ^ _ ^ Более плавный и безопасный, чем мой предыдущий основанный на rsnapshot solu

Примечание: slm связал меня здесь из дублированного вопроса: Назначение Rsnapshot целиком - как безопасно повторить?

1
ответ дан 6 August 2018 в 04:31

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

  rsync: сбой записи в «& lt; path & gt;»: на устройстве нет места (28)  

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

  1. Удалить последний каталог (например, daily.0)
  2. Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...);

Автоматически

rsnapshot не имеет паузы / (кроме ограниченного «, пропущенного из-за плана отката » 2 ), поэтому мы должны использовать обертку для обработки этих функций.

rsnapshot-once 3 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

  • работает без изменения вашей конфиги rsnapshot
  • гарантируют, что ежедневные, еженедельные и ежемесячные задания выполняются только один раз в соответствующий период времени, через cron (приятно для ноутбуков)
  • откат неудачной резервной копии (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последующие каталоги переименовываются, например, ежедневно1. -> daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резервном копировании и вуаля, удачный день ^ _ ^ Более плавный и безопасный, чем мой предыдущий основанный на rsnapshot solu

Примечание: slm связал меня здесь из дублированного вопроса: Назначение Rsnapshot целиком - как безопасно повторить?

1
ответ дан 7 August 2018 в 22:40

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

  rsync: сбой записи в «& lt; path & gt;»: на устройстве нет места (28)  

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

  1. Удалить последний каталог (например, daily.0)
  2. Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...);

Автоматически

rsnapshot не имеет паузы / (кроме ограниченного «, пропущенного из-за плана отката » 2 ), поэтому мы должны использовать обертку для обработки этих функций.

rsnapshot-once 3 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

  • работает без изменения вашей конфиги rsnapshot
  • гарантируют, что ежедневные, еженедельные и ежемесячные задания выполняются только один раз в соответствующий период времени, через cron (приятно для ноутбуков)
  • откат неудачной резервной копии (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последующие каталоги переименовываются, например, ежедневно1. -> daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резервном копировании и вуаля, удачный день ^ _ ^ Более плавный и безопасный, чем мой предыдущий основанный на rsnapshot solu

Примечание: slm связал меня здесь из дублированного вопроса: Назначение Rsnapshot целиком - как безопасно повторить?

1
ответ дан 10 August 2018 в 10:46

Это случилось со мной. мой внешний накопитель стал полным на полпути через инкрементное резервное копирование rsnapshot:

  rsync: сбой записи в «& lt; path & gt;»: на устройстве нет места (28)  

Теперь я хотел бы поделиться несколькими вещами, которые я узнал из этого. то есть отремонтировать и ограничить возможности для такого случая, чтобы укусить меня;)

Возобновить прерванное резервное копирование Rsnapshot

Я знаю два способа безопасного отката.

Вручную

  1. Удалить последний каталог (например, daily.0)
  2. Переименовать последовательные каталоги (ежедневно.1 -> daily.0, ...);

Автоматически

rsnapshot не имеет паузы / (кроме ограниченного «, пропущенного из-за плана отката » 2 ), поэтому мы должны использовать обертку для обработки этих функций.

rsnapshot-once 3 Philipp C. Heckel - это оболочка для rsnapshot в PHP, которая:

  • работает без изменения вашей конфиги rsnapshot
  • гарантируют, что ежедневные, еженедельные и ежемесячные задания выполняются только один раз в соответствующий период времени, через cron (приятно для ноутбуков)
  • откат неудачной резервной копии (проверяет, была ли последняя резервная копия завершена, если последний каталог не удален, а последующие каталоги переименовываются, например, ежедневно1. -> daily.0, ...)

Используя его в течение года, я счастливый пользователь: я отредактировал php.ini openbase_dir для моей потребности в резервном копировании и вуаля, удачный день ^ _ ^ Более плавный и безопасный, чем мой предыдущий основанный на rsnapshot solu

Примечание: slm связал меня здесь из дублированного вопроса: Назначение Rsnapshot целиком - как безопасно повторить?

1
ответ дан 13 August 2018 в 17:20

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

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