System backup

System backup Хостинг

Using Btrfs snapshots

See Btrfs#Snapshots, #Snapshots and /boot partition, and Snapper.

Using LVM snapshots

See LVM#Snapshots, Create root filesystem snapshots with LVM, and #Snapshots and /boot partition.

Using rsync

See rsync#As a backup utility.

Using tar

See Full system backup with tar.

Using SquashFS

See Full system backup with SquashFS.

Note: SquashFS does not support ACLs.

Bootable backup

Having a bootable backup can be useful in case the filesystem becomes corrupt or if an update breaks the system. The backup can also be used as a test bed for updates, with the testing repo enabled, etc. If you transferred the system to a different partition or drive and you want to boot it, the process is as simple as updating the backup’s /etc/fstab and your boot loader’s configuration file.

This section assumes that you backed up the system to another drive or partition, that your current boot loader is working fine, and that you want to boot from the backup as well.

Update the fstab

Without rebooting, edit the backup’s fstab by commenting out or removing any existing entries. Add one entry for the partition containing the backup like the example here:

/dev/sdaX / ext4 defaults 0 1

Remember to use the proper device name and filesystem type.

Update the boot loader’s configuration file

For Syslinux, all you need to do is duplicate the current entry, except pointing to a different drive or partition.

Tip: Instead of editing syslinux.cfg, you can also temporarily edit the menu during boot. When the menu shows up, press the Tab key and change the relevant entries. Partitions are counted from one, drives are counted from zero.

For GRUB, it is recommended that you automatically re-generate the main configuration file. If you want to freshly install all GRUB files to somewhere other than /boot, such as /mnt/newroot/boot, use the --boot-directory flag.

Also verify the new menu entry in /boot/grub/grub.cfg. Make sure the UUID is matching the new partition, otherwise it could still boot the old system. Find the UUID of a partition with lsblk:

$ lsblk -no NAME,UUID /dev/sdXY

where /dev/sdXY is the desired partition (e.g. /dev/sdb3). To list the UUIDs of partitions GRUB thinks it can boot, use grep:

# grep UUID= /boot/grub/grub.cfg

Reboot the computer and select the right entry in the boot loader. This will load the system for the first time. All peripherals should be detected and the empty folders in / will be populated.

Now you can re-edit /etc/fstab to add the previously removed partitions and mount points.

Snapshots and /boot partition

If your file system supports snapshots (e.g., LVM or Btrfs), these will most likely exclude the /boot partition or ESP.

You can copy the boot partition automatically on a kernel update to your root partition with a pacman hook (make sure the hook file is owned by root):

/etc/pacman.d/hooks/95-bootbackup.hook
[Trigger]
Operation = Upgrade
Operation = Install
Operation = Remove
Type = Path
Target = usr/lib/modules/*/vmlinuz
[Action]
Depends = rsync
Description = Backing up /boot...
When = PostTransaction
Exec = /usr/bin/rsync -a --delete /boot /.bootbackup

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: Uses a half-baked script instead of explaining basic options and referring to the manual, duplication with articles such as Help:Reading, numerous Help:Style issues (Discuss in Talk:Full system backup with tar)

This article will show you how to do a full system backup with tar.

Backing up with tar has the advantages of using compression that can help save disk space, and simplicity. The process only requires several steps, they are:

  1. Boot from a LiveCD
  2. Change root to the Linux install
  3. Mount additional (if any) partitions/drives
  4. Add exclusions
  5. Use the backup script to backup

To minimize downtime the backup can alternatively be performed on a running system using LVM snapshots,
if all filesystems reside on LVM volumes.

Boot with LiveCD

Many Linux bootable CDs, USBs… have the ability to let you change root to your install. While changing root is not necessary to do a backup, it provides the ability to just run the script without need to transfer it to a temporary drive or having to locate it on the filesystem. The Live medium must be of the same architecture that your Linux install currently is (i.e. i686 or x86_64).

Changing root

# mkdir /mnt/arch
# mount /dev/your-partition-or-drive

Use fdisk -l to discover you partitions and drives. Now chroot:

# cd /mnt/arch
# chroot . /bin/bash

Warning: Do not use arch-chroot to chroot into the target system — the backup process will fail as it will try to back up temporary file systems, all system memory and other interesting things. Use plain chroot instead.

This example obviously uses bash but you can use other shells if available. Now you will be in your scripted environment (this is provided that you have your ~/.bashrc sourced on entry):

~/.bash_profile
# If using bash, source the local .bashrc
source ~/.bashrc

Mount other partitions

Other partitions that you use (if any) will need to be mounted in their proper places (e.g. if you have a separate /home partition).

Exclude file

tar has the ability to ignore specified files and directories. The syntax is one definition per line. tar also has the capability to understand regular expressions (regexps). For example:

# Not old backups
/opt/backup/arch-full*
# Not temporary files
/tmp/*
# Not the cache for pacman
/var/cache/pacman/pkg/
...

Backup script

Backing up with bsdtar is straight-forward process. Here is a basic script that can do it and provides a couple checks. You will need to modify this script to define your backup location, and exclude file (if you have one), and then just run this command after you have chrooted and mounted all your partitions. Note that GNU tar with --xattrs will not preserve extended attributes.

#!/bin/bash
# full system backup
# Backup destination
backdest=/opt/backup
# Labels for backup name
#PC=${HOSTNAME}
pc=pavilion
distro=arch
type=full
date=$(date "+%F")
backupfile="$backdest/$distro-$type-$date.tar.gz"
# Exclude file location
prog=${0##*/} # Program name from filename
excdir="/home/<user>/.bin/root/backup"
exclude_file="$excdir/$prog-exc.txt"
# Check if chrooted prompt.
echo -n "First chroot from a LiveCD. Are you ready to backup? (y/n): "
read executeback
# Check if exclude file exists
if [ ! -f $exclude_file ]; then echo -n "No exclude file exists, continue? (y/n): " read continue if [ $continue == "n" ]; then exit; fi
fi
if [ $executeback = "y" ]; then # -p, --acls and --xattrs store all permissions, ACLs and extended attributes. # Without both of these, many programs will stop working! # It is safe to remove the verbose (-v) flag. If you are using a # slow terminal, this can greatly speed up the backup process. # Use bsdtar because GNU tar will not preserve extended attributes. bsdtar --exclude-from=$exclude_file --acls --xattrs -cpvzf $backupfile /
fi

Restoring

To restore from a previous backup, mount all relevant partitions, change the current working directory to the root directory, and execute

Читайте также:  5 простых шагов по использованию инструмента Ping Checker для получения быстрых и точных результатов

$ bsdtar --acls --xattrs -xpzf backupfile

replacing backupfile with the backup archive. Removing all files that had been added since the backup was made must be done manually. Recreating the filesystem(s) is an easy way to do this.

Backup with parallel compression

To back up using parallel compression (SMP), use (Parallel bzip2):

# bsdtar -cvf /path/to/chosen/directory/etc-backup.tar.bz2 -I pbzip2 /etc

Store etc-backup.tar.bz2 on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups. Possibly maintain a list of hashes of the backed up files to make the comparison quicker.

# bsdtar -xvf etc-backup.tar.bz2 -C /

В инструкции описан процесс создания резервной копии системы с операционной системой Linux с помощью утилиты dd и tar.

Что это такое?

Резервное копирование (backup) — создание запасных копий серверов, может быть настроено по регулярному расписанию, а может выполняться однократно в удобный для пользователя момент. Преимущество в использовании утилит tar и dd — они являются предустановленными и просты в использовании.

Создание резервной копии с помощью dd

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

Чтобы сделать запасную копию вашего жесткого диска используйте следующую команду:

dd if=<исходный_диск> of=<полное_имя_копии> bs=8M conv=sync,noerror

dd if=/dev/sda of=/mnt/backup/sda.img bs=8M conv=sync,noerror

  • if=/dev/sda — копируем весь жесткий диск sda;
  • of=/mnt/backup/sda.img — копируем в /mnt/backup/sda.img, где каталог /mnt/backup точка монтирования диска, на котором будет содержаться образ;
  • bs=8M — задаем размер кэша жесткого диска для ускорения процедуры копирования (иначе данные будут сбрасываться малыми порциями по 512 байт);
  • conv=sync,noerror — указываем dd на необходимость копирования по типу бит-в-бит с игнорированием ошибок чтения.

Примечание: на целевом диске должно быть достаточно места, т.е. не менее того объема, который занимает исходный диск.

Восстановление из резервной копии с помощью dd

Чтобы сделать восстановление вашего жесткого диска из резервной копии используйте следующую команду:

dd if=<полное_имя_копии> of=<целевой_диск> bs=8M conv=sync,noerror

dd if=/mnt/backup/sda.img of=/dev/sda bs=8M conv=sync,noerror

Создание резервной копии с помощью tar

Команда tar в Linux часто используется для создания архивов .tar.gz или .tgz, также называемых «tarballs». Эта команда имеет большое количество опций, для работы с архивами, но также с помощью нее можно создать резервную копию системы.

Чтобы сделать бекап вашей системы используйте следующую команду:

tar -cvpzf <имя_файла>.tar.gz --exclude=<имя_файла> --one-file-system <целевой_каталог>

tar -cvpzf backup.tar.gz --exclude=/backup.tar.gz --one-file-system /

  • c — создать новый резервный архив;
  • v — подробный режим, при котором выводится информация о текущих действиях;
  • p — сохранить права доступа на файлы;
  • z — сжать с помощью утилиты gzip;
  • f <имя_файла> — полное имя файла с резервной копией.
  • —exclude=<имя_файла> — имена файлов или каталогов, которые необходимо исключить из резервной копии.
    Важно: во избежании ошибок обязательно нужно исключить файл с резервной копией.
  • —one-file-system — создать копию только одной файловой системы, т.е. если у вас есть смонтированные носители с другими файловыми системами, то они не будут включены в копию, их необходимо резервировать отдельно или использовать дополнительные опции.
  • / — в конце нужно указать каталог, запасную копию которого необходимо создать.

Восстановление из резервной копии с помощью tar

Для восстановления из резервной копий вашей системы используйте следующую команду:

sudo tar -xvpzf <имя_файла> -C <имя_каталога> --numeric-owner

sudo tar -xvpzf /path/to/backup.tar.gz -C /media/whatever --numeric-owner

  • f <имя_файла> — полное имя файла с резервной копией;
  • -C <имя_каталога> — каталог в который произойдет восстановление;
  • —numeric-owner — опция позволяет восстановить пользователей файлов по числовому дескриптору, а не по имени, во избежании ошибок.

Создавать резервную копию очень удобно по настроенному расписанию, о том как настроить планировщик Linux Cron читайте в нашей статье. Это позволит автоматизировать создание копий сервера или данных.

Примечание:
В рамках нашего сервиса есть услуга резервного копирования серверов, копирование выполняется 1 раз в сутки на территориально удаленный дисковый массив, при этом вам не нужно самостоятельно выполнять настройки резервирования, а сохранность копии не зависит от работоспособности сервера.

Тестирование сервера


Резервное копирование Linux серверов встроенными средствами

Резервное копирование Linux серверов встроенными средствами

28 августа 2020 11:42

System backup

Visitors have accessed this post 3845 times.

Автор — Максим Рязанов

Предисловие

Резервное копирование и восстановление ОС — базовый навык, которым должен обладать любой системный администратор. Поэтому давайте на примере практической задачи разберем, как это сделать в ОС Linux.

Допустим, что у нас есть ОС, все данные которой хранятся в одном разделе. Эту ОС необходимо мигрировать на другой сервер.

Гайд предполагает, что / (корень) — ваш загрузочный, если вы используете разметку диска MBR.

Из доступных средств у нас — только LiveCD/DVD/USB для резервного копирования и развертки системы. Системы резервного копирования отсутствуют.

Резервное копирование

Начнем мы с резервного копирования.

Шаг 0. Загружаемся с Live системы.

Шаг 1. Монтируем накопитель, на который будет производиться резервное копирование системы (директория монтирования ФС накопителя резервных копий в примере будет /media/backupdisk1, система смонтирована в /mnt).

Читайте также:  Раскрытие невидимого: решение проблемы отсутствия просмотра вашего сайта

Шаг 2. Создаем архив с резервной копией.

Команда архивации системы

tar cpJvf /media/backupdisk1/our_backup.xz --selinux --exclude /mnt/dev --exclude /mnt/proc --exclude /mnt/sys --exclude /mnt --exclude /media --exclude /mnt/lost+found --exclude /mnt/tmp /mnt/

Описание опций tar:

  • с — create — создать;
  • p — сохраняем владельцев файлов и права к файлам;
  • J — используем компрессию xz;
  • v — verbose, чтобы видеть, что происходит во время архивации;
  • f — указываем файл, куда мы хотим сохранить копию/архив;
  • — -exclude — исключить из архивации директории и файлы. Из архива исключаются каталоги, структура которых создается при загрузке операционной системы, в связи с чем нет смысла добавлять их в архив.
  • — -selinux — сохраняем контексты SElinux, примененные к файлам. Используйте только при наличии в системе SElinux и его поддержки tar (как правило, присутствует в актуальных системах)!

Шаг 3. Демонтируем раздел накопителя, на который архивировали систему.

Восстановление из резервной копии

Шаг 0. Загружаемся с Live системы.

Шаг 1. Неплохо бы для начала развернуть базовую систему на диске для восстанавливаемой ОС.

Или создаем разметку диска и разделы на нем.

Шаг 2. Монтируем накопитель с резервной копией (в нашем примере — /media/backupdisk1, а корень установленной ОС примонтирован в /mnt).

Шаг 3. Распаковываем копию.

tar -xvpfJ --selinux /media/backupdisk1/our-backup.xz -C /mnt/

Описание опций tar:

  • x — extract, вытащить данные из архива;
  • v — verbose, чтобы видеть, что происходит во время разархивации;
  • p — сохраняем владельцев файлов и права к файлам;
  • f — указываем, из какого файла мы хотим восстановить копию/архив;
  • J — указываем при распаковке, что у нас используется компрессия xz;
  • -C — create. Восстановить структуру каталогов, воссоздав отсутствующие.
  • — -selinux — сохраняем контексты SElinux, примененные к файлам. Использовать только при наличии в системе SElinux и его поддержки tar!

Шаг 4. Если мы выполняем разархивацию не в готовую систему, восстановим директории, которые мы исключили из архивации, а также восстановим правильные права доступа к ним.

mkdir {/mnt/dev,/mnt/proc,/mnt/sys,/mnt/mnt,/mnt/media,/mnt/tmp,/mnt/lost+found}
chmod -R 777 {/mnt/tmp,/mnt/mnt,/mnt/media}
# или
chmod -R 755 {/mnt/mnt,/mnt/media}
chmod -R 777 /mnt/tmp
# конец или
chmod -R 755 /mnt/dev
chmod -R 555 {/mnt/proc,/mnt/sys}
# в случае наличия SElinux в системе укажем созданным директориям их контексты:
chcon -R system_u:object_r:boot_t:s0 /mnt/boot
chcon -R system_u:object_r:device_t:s0 /mnt/dev
chcon -R system_u:object_r:proc_t:s0 /mnt/proc
chcon -R system_u:object_r:sysfs_t:s0 /mnt/sys
chcon -R system_u:object_r:mnt_t:s0 {/mnt/media,/mnt/mnt}
chcon -R system_u:object_r:tmp_t:s0 /mnt/tmp
chcon -R system_u:object_r:lost_found_t:s0 /mnt/lost+found
# или для восстановления контекстов перед загрузкой системы автоматически создайте в корне файл .autorelabel
touch /mnt/.autorelabel # может занять очень много времени при наличии большого количества мелких файлов, но надежно и корректно расставит контексты перед загрузкой системы!

Обратите внимание! Для работы с SElinux при восстановлении ваша live система и утилита tar в ее составе должны поддерживать SElinux.

Восстановление загрузчика для MBR

Обратите внимание на этот пункт, если используете разметку диска MBR и развертку НЕ поверх установленной ранее системы.

Для проверки работоспособности системы и установки загрузчика необходимо выполнить следующие операции:

Шаг 0. Монтируем уже рабочие служебные каталоги из live системы в восстановленную.

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt # CHangeROOT - меняем корневой каталог. Теперь корнем будет корень восстановленной системы

Вызов bind mount присоединяет (частично) только одну файловую систему, а не возможные дополнительные монтирования в директории внутри нее. Вся файловая иерархия, включая дополнительные монтирования внутри монтируемой ФС, остается на своем месте.

Далее проверим, на каком диске у нас система:

root@rpulse ~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 253:0 0 25G 0 disk
└─vda1 253:1 0 25G 0 part /
root@rpulse ~ #

Наш диск — vda.

Установим туда загрузчик, потом сконфигурируем:

grub-install /dev/vda # установка
# далее все зависит от того, какой версии grub у вас
# не используйте следующие две команды поочередно, проверьте доступность первой!
update-grub # один из вариантов конфигурации
grub-mkconfig -o /boot/grub/grub.cfg # другой

Далее поправим наш fstab. Выполним команду blkid для идентификации UUID разделов. И после правим fstab.

root@rpulse ~ /dev/vda1: UUID="0ae7ab5c-e4e2-4641-87ad-d02b494b6553" TYPE="ext4"
# потом указываем их в fstab
root@rpulse ~ nano /etc/fstab
#
# /etc/fstab
# Created by anaconda on Fri Jan 5 21:10:34 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=0ae7ab5c-e4e2-4641-87ad-d02b494b6553 / ext4 defaults 1 1
/swapfile swap swap sw 0 0

Или мы можем использовать вместо UUID — лейблы (labels). Помните, что в отличие от UUID, labels могут быть не уникальны.

root@rpulse ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 253:0 0 25G 0 disk
└─vda1 253:1 0 25G 0 part /
root@rpulse ~ nano /etc/fstab
#
# /etc/fstab
# Created by anaconda on Fri Jan 5 21:10:34 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/vda1 / ext4 defaults 1 1
/swapfile swap swap sw 0 0

Теперь демонтируем разделы из live.

# выходим из chroot
root@rpulse ~ exit # или CTRL+d
# демонтируем разделы из live
root@rpulse ~ umount /mnt/{dev,proc,sys}

А потом и раздел разархивированной системы и носителя с бэкапом.

Восстановление загрузчика UEFI

Обратите внимание на этот пункт, если используете разметку диска GPT и UEFI loader.

В данном примере будет использоваться конфигурация systemd-boot.

Монтируем esp в /mnt/boot.

Вместо $(osconfigname) подставьте имя вашего конфига, указанного в esp/loader/loader.conf.

root@rpulse ~ blkid
/dev/vda1: UUID="0ae7ab5c-e4e2-4641-87ad-d02b494b6553" TYPE="ext4"
/dev/vda2: UUID="14420948-2cea-4de7-b042-40f67c618660" TYPE="vfat"
root@rpulse ~ nano esp/loader/entries/$(osconfigname).conf
esp/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw

Заключение

Если вы повторили путь, описанный в статье, полностью — ура, теперь вы умеете делать резервное копирование и восстановливать ОС Linux. Если у вас возникли вопросы на каком-либо этапе, задавайте их в комментариях к статье, обязательно подскажем.

Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN

*Анонсы мероприятий каждую неделю

Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.

Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.

Состояние перевода: На этой странице представлен перевод статьи Synchronization and backup programs. Дата последней синхронизации: 3 января 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Эта статья содержит список и сравнение программ для синхронизации данных между двумя и более местоположениями, а также программ с расширенными возможностями, например, инкрементным резервным копированием. Данные темы достаточно схожи между собой и, соответственно, описываются в одной статье.

Введение в резервное копирование

Создание резервных копий является необходимой мерой, поскольку ошибки, совершаемые людьми и машинами, могут приводить к повреждению данных; физические носители также разрушаются со временем и однажды перестают работать. Чтобы выбрать лучшую программу для своих нужд, нужно учесть следующие моменты:

  • тип носителя данных, используемый для резервных копий: CD, DVD, удалённый сервер, внешний жёсткий диск и т.д.;
  • планируемая частота создания резервных копий: ежедневно, еженедельно, ежемесячно и т.д.;
  • возможности, ожидаемые от инструмента: сжатие, шифрование, обработка переименований и т.д.;
  • планируемый метод восстановления резервных копий при необходимости.
Читайте также:  Mikrotik 2 провайдера резервный канал

Синхронизация данных

Эти приложения просто «зеркалируют» содержимое каталогов по нескольким местам. Тем не менее большинство из них позволяют сохранять и возвращать старые версии изменённых или удалённых файлов.

Название
Название приложения, со ссылкой на ArchWiki или официальный сайт.
Пакет
Ссылка на пакет.
Реализация
Язык программирования, библиотеки или утилиты, на базе которых создано приложение.
Delta transfer
Передача только изменённых частей файла.
Зашифрованная передача
Передача данных зашифрованном виде по умолчанию при использовании сети.
Метаданные ФС
Сохранение прав доступа и атрибутов файловой системы.
Возобновляемая
Возможность возобновления синхронизации в случае её прерывания.
Переименования
Перемещённые/переименованные файлы определяются и не хранятся или не передаются дважды. Обычно это означает подсчёт хеш-сумм файлов или их частей. Приложения без поддержки этого можно комбинировать с AUR, который синхронизирует только переименования.
Контроль версий
Сохранение старых версий файла (reverse incremental backup).
Передача изменений
В каких направлениях могут передаваться изменения.
  • односторонняя синхронизация между двумя местами;
  • двухсторонняя синхронизация между двумя местами;
  • многосторонняя — полная синхронизация между более чем двумя местами.
Решение конфликтов
Обработка конфликтов файлов, автоматически или интерактивно, то есть приложение не отклоняет конфликтующие файлы молча. Неприменимо для приложений с односторонней синхронизацией.
Мониторинг ФС
Обработка приложением событий файловой системы для запуска синхронизации.
CLI
Наличие у приложения интерфейса командной строки.
Другие интерфейсы
Наличие указанных пользовательских интерфейсов, например GUI, TUI или web.
Лицензия
Лицензия серверного и клиентского приложения.
Другие платформы
Поддержка других операционных систем помимо Linux.
Поддержка
Поддерживается ли сейчас проект разработчиками.
Особенности
Заметки об особых функциях, которые выделяют приложение среди других.

Инкрементное резервное копирование

Приложения, которые могут создавать инкрементные резервные копии, запоминают и учитывают, какие данные были скопированы во время последнего запуска (так называемые «различия») и устраняют необходимость хранить дубликаты неизменённых данных. Восстановление данных к определённому моменту времени потребует размещения последней полной резервной копии и всех инкрементных резервных копий с того момента, когда предполагается, что они будут восстановлены. Этот вид резервных копий полезен для тех, кто делает их очень часто.

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

Инкременты на основе блоков данных

При изменении файла приложении сохраняют только изменившиеся части в следующем снимке. В отличие от инкрементов на основе файлов, они более экономно расходуют место, особенно когда есть большие файлы с малыми изменениями; с другой стороны, такие резервные копии могут быть прочитаны только тем приложением, которое их создало, так как исходные файлы должны быть реконструированы по сохранённым в копии различиям между версиями.

Инкременты на основе файлов

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

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

  • Жёсткие ссылки: хранение неизменённых файлов в виде жёстких ссылок на предыдущие версии.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Эти приложения были разработаны для централизованного архивирования данных с нескольких машин, соединённых по сети, с использованием клиент-серверной модели. В целом они более сложны в развёртывании в сравнении с реализациями для одного устройства.

  • Направление: Pull: сессия архивирования инициализируется сервером. Push: сессия архивирования инициализируется клиентом.
  • Тип инкремента: стратегия уменьшения дублирования данных для экономии места (помимо сжатия).
    • на основе файлов: при изменении файла в новом снимке сохраняется новая версия целиком.
      • с жёсткими ссылками: хранение неизменённых файлов в виде жёстких ссылок на предыдущие версии.
    • на основе блоков данных: при изменении файла в снимке хранятся только изменённые части.

Системы управления версиями

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

См. List of applications/Utilities#Version control systems и dotfiles.

Смотрите также

  • Краткий обзор open source средств резервного копирования
  • Backing up Linux and other Unix(-like) systems
  • Exhaustive list of backup solutions for Linux
  • Performance comparison of five remote incremental backup tools: Rsync, Rdiff-backup, Duplicity, Areca and Link-Backup
  • Mirroring an Entire Site using Rsync over SSH
  • Performance comparison of five remote incremental backup tools: Rsync, Rdiff-backup, Duplicity, Areca and Link-Backup
  • rsync-snapshots.sh rsync-snapshot.sh — Local and remote snapshot backup using rsync with hard links

Here is a solution I use with SquashFS. It is quite similar to TAR.GZ solution proposed earlier, but has some major benefits.

SquashFS is a compressed file system, which is completely stored in one file. This file can be mounted to an existing system and accessed in a usual way, like any other partition. The difference to TAR.GZ is that SquashFS is a full-blown file system with random access to files, while TAR is just one big concatenated file.

This means that if you want to mount some large backup of your whole file system, for TAR.GZ it would take like 5 hours (in my experience) and for SquashFS it would take just minutes/seconds. The same is true also for the compression/backup operation, SquashFS is many times faster.

UPDATE 2017-01-31:
It appears that not only can you mount squashfs file, but also open it as a usual archive with familiar apps like File Roller on Linux and 7-Zip on Windows, etc.

So here is a command I use to back up my root folder:

sudo mksquashfs / /path/to/backup/hdd/root-backup.sqsh -e home media dev run mnt proc sys tmp

where «-e» switch excludes folders you want to exclude (like virtual and external Linux folders in my example).

After the backup is done, I can now mount it:

sudo mkdir /mnt/root_backup
sudo mount /path/to/backup/hdd/root-backup.sqsh /mnt/root_backup -t squashfs -o loop

Now just wait couple minutes (depending on size of the archive) and enjoy all your files at /mnt/root_backup folder.

Same can be done for /home/myname folder, e.g.

sudo mksquashfs /home/myname /path/to/backup/hdd/home-backup.sqsh -e Dropbox GoogleDrive

I exclude Dropbox and GoogleDrive here to avoid any potential problems in the future, in case I restore those folders from backup and they become messing with the actual files in the cloud.

Check more info at http://tldp.org/HOWTO/SquashFS-HOWTO/creatingandusing.html

Оцените статью
Хостинги