резервне копіювання: щось готове чи diy?

2023-12-24, 17:01 | щоденник, комп'ютери, linux, сервер, поновлюється

перш як продовжувать міграцію контейнерів на сервер v2, треба врешті-решт вирішити задачу збереження резервної копії сховища owncloud, — за чотири роки «тестового» використання там накопичилося чимало справді важливих документів; як не соромно визнавати, але досі всі ці дані лежать на одному hdd без резервування (щоправда, це не зовсім так: owncloud тримає синхронізовану копію найважливішої частини даних на моєму лептопі). треба терміново знайти open source варіант, котрий був би достатньо простий (бо простота — передумова надійності), безкоштовний і використовував би вже наявні ресурси, дозволяв би просте масштабування на декілька машин (nextcloud на сервері v2 також треба буде бекапити) і, в перспективі, на віддалене зберігання (холодне сховище amazon, чи обмін вільним місцем з товаришем тощо).

наразі я не маю готового «найкращого» рішення, схиляюсь до думки написати собі з нуля більш чи менш розумний скрипт, котрий би рекурсивно архівував задану теку повністю чи інкрементально, і вмів би шукати й відновлювати з архівів версії файлів на певну дату. але перш ніж робити щось самому — варто поглянути, чи нема готового рішення.

зміст

огляд готових рішень

огляд готових рішень

резервне копіювання (і відновлення!) — одна з найпоширеніших, найважливіших задач будь-якого сисадміна, тому програм для цього існує достобіса; але в мене трохи специфічні вимоги (див. вище), тож далеко не все підходить.

backuppc

колись по роботі мені довелося використовувати backuppc (документація) як основний засіб резервування даних в мережі: написано на perl’і, має трохи заплутаний, але придатний для використання веб-інтерфейс, підтримує затягування даних з віддалених машин по smb, rsync та ftp, дозволяє вельми гнучко налаштовувати розклад збереження й утримування копій, і гранульовано відновлювати потрібну версію конкретного файлу чи групи…

але все це потребує кропіткого налаштування і підтримки; зокрема, аж ніяк не хочеться залежати від веб-сервера для копіювання-відновлення. це приблизна верхня межа складності, яку я готовий розглядати для домашньої мережі… але в ідеалі хочеться щось простіше.

(до змісту)

rsnapshot

ніколи не користувався rsnapshot (документація), але це дуже близько за ідеологією до того, що мені треба: написано на perl’і, використовує rsync, hard links, і ssh для віддаленого копіювання, вельми просте у використанні, простий доступ до окремих файлів. але, на жаль, не стискає — це інструмент для зберігання знятків (snapshots), а не архівування.

я трохи погрався з ним. встановлення (arch та похідні), і основні налаштування в /etc/rsnapshot.conf (важлива заувага: значення налаштувань від назв відділяються tab’ами, не пробілами):

> sudo pacman -Ss rsnapshot
> sudo vim /etc/rsnapshot.conf
# ----- >8 -----
snapshot_root	/home/tivasyk/temp/backup/
...
retain	hourly	3
retain	daily	7
retain	weekly	4
retain	monthly	3
...
backup	/home/tivasyk/temp/data/		katana.lan/
# ----- 8< -----
> rsnapshot configtest

майданчик для випробувань:

> mkdir -p ~/temp/data
> mkdir -p ~/temp/backup
> cd ~/temp
# генерація кількох файлів для випроби
> for i in tar gzip; do man ${i} > data/${i}.txt; done
# структура до знятка №1
> tree ~/temp
/home/tivasyk/temp
├── backup
└── data
    ├── gzip.txt
    └── tar.txt

назви знятків hourly, daily тощо — довільні, але порядок важливий, і зробити daily не вийде, поки не набереться достатня кількість знятків першого рівня. перший прогін rsnapshot:

> [sudo] rsnapshot hourly
# структура після знятка №1
/home/tivasyk/temp
├── backup
│   └── hourly.0
│       └── katana.lan
│           └── home
│               └── tivasyk
│                   └── temp
│                       └── data
│                           ├── gzip.txt
│                           └── tar.txt
└── data
    ├── gzip.txt
    └── tar.txt

кожен наступний зняток hourly додаватиме нову теку (backup/hourly.1 тощо), і rsnapshot сам робить ротацію всередині кожного рівня (hourly, daily тощо):

> man bzip2 > data/bzip2.txt
> [sudo] rsnapshot hourly
> tree ~/temp
/home/tivasyk/temp
├── backup
│   ├── hourly.0
│   │   └── katana.lan
│   │       └── home
│   │           └── tivasyk
│   │               └── temp
│   │                   └── data
│   │                       ├── bzip2.txt
│   │                       ├── gzip.txt
│   │                       └── tar.txt
│   └── hourly.1
│       └── katana.lan
│           └── home
│               └── tivasyk
│                   └── temp
│                       └── data
│                           ├── gzip.txt
│                           └── tar.txt
└── data
    ├── bzip2.txt
    ├── gzip.txt
    └── tar.txt

видно, як відбулася ротація: hourly.0 став hourly.1; час створення тек підказує:

> ls -l backup/
drwxr-xr-x 3 root root 4096 гру 24 17:04 hourly.0
drwxr-xr-x 3 root root 4096 гру 24 16:57 hourly.1

окрема команда (потребує du) показує, скільки зайнято місця під кожен зняток, і загалом, — тут видно, що за рахунок hard links знятки потребують місця лише під змінені/додані файли:

> rsnapshot du
108K    /home/tivasyk/temp/backup/hourly.0/
24K     /home/tivasyk/temp/backup/hourly.1/
132K    загалом

як відновлювати втрачені файли? просто скопіювати, що куди треба, та й по тому. для архівування доведеться tar’ити теку останнього знятка (додаткова дія, додатковий простір на диску), стискати, шифрувати, — і можна синхронізувати кудись.

загалом, rsnapshot мені дуже сподобався простотою і надійністю. але це не зовсім те, що мені треба: для резервування майже 500 гб даних мені потрібне архівування, а для віддаленого зберігання — ще й шифрування.

(до змісту)

amanda

спершу хотів «скинути» цей інструмент до розділу «інші опції» як потенційно цікавий, але заскладний для домашнього використання… але щось у описі підштовхнуло одразу спробувати, тож: amanda (документація).

налаштування

встановлення (на arch і похідних, з aur)…

> pamac install amanda

…завершується аварійно на моїй системі, довелося скористатися детальною підказкою:

> [sudo] pacman -S --needed base-devel git
> pamac install amanda

після цього на позір встановилося: в /usr/bin/ з’явилося багато утиліт am*, що належать групі amandabackup:

> [sudo] find /usr/bin -group amandabackup
...
/usr/bin/amadmin
...
/usr/bin/amstatus
...
> [sudo] amadmin --version
amadmin-3.5.2
> man amadmin
DUMMY

тиць, а маєш… на жаль, пакувальник до aur «забув» додати сторінки man до всього цього; man’и є у wiki на zmanda.com. щоби не блукати навпомацки надто довго, мені знадобиться підказка з прикладами… але поки що досліджую:

> [sudo] tree /etc/amanda/
/etc/amanda/
├── example -> /usr/share/amanda/example/
├── MyConfig
│   ├── amanda.conf
│   ├── curinfo
│   ├── disklist
│   └── index
└── template.d -> /usr/share/amanda/template.d/
> [sudo] less /etc/amanda/MyConfig/amanda.conf
...

гаразд, починається цікаве: користуючись man‘ами, підказкою та наявним конфігом як взірцем, спробую щось забекапити. найперше видаляю результати випроби rsnapshot і готую майданчик для експериментів:

> cd ~/temp
> [sudo] rm -rf backup/*
> tree ~/temp/
/home/tivasyk/temp/
├── backup
└── data
    ├── bzip2.txt
    ├── gzip.txt
    └── tar.txt

я не хочу зберігати службову інформацію разом з конфігом в /etc/amanda/, принаймні не для тестів, тому…

> mkdir -p ~/temp/amanda/state/{curinfo,log,index}

там же буде кеш для тимчасового пакування архіву перед скиданням в бекап (віртуальна «магнітна плівка», відчуй себе сисадміном середини восьмидесятих!):

> mkdir ~/temp/amanda/holding

…і теки, які емулюватимуть ті «плівки» — власне, архівовані резервні копії, три штуки для випроби ротації:

> mkdir -p ~/temp/backup/vtapes/slot{1,2,3}
> tree ~/temp/
/home/tivasyk/temp/
├── amanda
│   ├── holding
│   └── state
│       ├── curinfo
│       ├── index
│       └── log
├── backup
│   └── vtapes
│       ├── slot1
│       ├── slot2
│       └── slot3
└── data
    ├── bzip2.txt
    ├── gzip.txt
    └── tar.txt

черга конфігурації; на хочу використовувати наявним MyConfig — створю собі копію tivasyk.test:

> su root
> su amandabackup
> mkdir /etc/amanda/tivasyk.test
> cp /etc/amanda/MyConfig/{amanda.conf,disklist} /etc/amanda/tivasyk.test
> tree /etc/amanda/
/etc/amanda/
├── example -> /usr/share/amanda/example/
├── MyConfig
│   ├── amanda.conf
│   ├── curinfo
│   ├── disklist
│   └── index
├── template.d -> /usr/share/amanda/template.d/
└── tivasyk.test
    ├── amanda.conf
    └── disklist

зараз уважний читач запитає, навіщо була ось ця дивна конструкція:

> su root
> su amandabackup

все просто: користувач amandabackup не призначений для того, щоби ним логінилися в консоль, тому він не має пароля (див. :!: в /etc/shadow):

> sudo grep amandabackup /etc/passwd
mandabackup:x:112:112:Amanda Backup Daemon:/var/lib/amanda:/bin/bash
> sudo grep amandabackup /etc/shadow
amandabackup:!:19716:0:99999:7:::

тому, якщо треба запустити одну команду як amandabackup, достатньо sudo -u amandabackup <команда>, але щоби відкрити консоль як amandabackup, можна спершу стати root’ом, якому не потрібен дозвіл чи пароль іншого користувача, щоби переключитися на його профіль. отже, лізу руцями до конфігурації:

> vim /etc/amanda/tivasyk.test/amanda.conf
# ----- >8 -----
org "tivasyk.lan"
infofile "/home/tivasyk/temp/amanda/state/curinfo"
logdir "/home/tivasyk/temp/amanda/state/log"
indexdir "/home/tivasyk/temp/amanda/state/index"
dumpuser "amandabackup"

tpchanger "chg-disk:/home/tivasyk/temp/backup/vtapes"
labelstr "MyData[0-9][0-9]"
autolabel "MyData%%" EMPTY VOLUME_ERROR
tapecycle 3
dumpcycle 1 days
amrecover_changer "changer"

tapetype "TEST-TAPE"
define tapetype TEST-TAPE {
    length 100 mbytes
    filemark 4 kbytes
}

define dumptype simple-gnutar-local {
    auth "local"
    compress none
    program "GNUTAR"
}

holdingdisk test {
    comment "for local test only"
    directory "/home/tivasyk/temp/amanda/holding"
    use 100 mbytes
    chunksize 1 mbyte
}
# ----- 8< -----

окремо, в /etc/amanda/tivasyk.test/disklist формується перелік дисків, розділів чи тек для резервного архівування:

> vim /etc/amanda/tivasyk.test/disklist
# ----- >8 -----
localhost /home/tivasyk/temp/data simple-gnutar-local
# ----- 8< -----

можна спробувати перевірити конфігурацію на помилки:

> amcheck tivasyk.test
ERROR: must be executed as the 'amandabackup' user instead of the 'root' user
       Change user to 'amandabackup' or change dumpuser to 'root' in amanda.conf

зрозуміло: amanda вимагає запуску від користувача, вказаного як umpuser "amandabackup" в amanda.conf. друга спроба:

> sudo -u amandabackup amcheck tivasyk.test
ERROR: tapelist dir '/etc/amanda/tivasyk.test': not writable: Permission denied                                                                                                                                 
       check permissions
ERROR: holding disk '/home/tivasyk/temp/amanda/holding': not writable: Permission denied
       check permissions                                                                                
ERROR: log dir '/home/tivasyk/temp/amanda/state/log' (Permission denied): not writable

очікувано: я не налаштовував права доступу до тестових тек ~/temp/amanda та ~/temp/backup; права доступу треба буде продумати, але для випроби буде достатньо такого:

> sudo chown -R tivasyk:amandabackup /home/tivasyk/temp/{amanda,backup}
> sudo chmod -R ug+w /home/tivasyk/temp/{amanda,backup}

третя спроба:

> sudo -u amandabackup tivasyk.test
Amanda Tape Server Host Check
-----------------------------
NOTE: tapelist file does not exists
      it will be created on the next run
NOTE: Holding disk '/home/tivasyk/temp/amanda/holding': 34856960 KB disk space available, using 102400 KB as requested
slot 1: contains an empty volume
Will write label 'MyData01' to new volume in slot 1.
NOTE: skipping tape-writable test
NOTE: host info dir '/home/tivasyk/temp/amanda/state/curinfo/localhost' does not exist
      It will be created on the next run
NOTE: index dir '/home/tivasyk/temp/amanda/state/index/localhost' does not exist
      it will be created on the next run
Server check took 0.177 seconds
Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 2.135 seconds.  0 problems found.
(brought to you by Amanda 3.5.2)

резервне архівування

чи є якісь зміни/доповнення в теках ~/temp/? в теці ~/temp/backup/vtapes/ з’явилося посилання (soft link) data -> slot1 — ймовірно, позначає поточну «плівку», яка (див. конфігурацію) має розмір 100 мб? час експерименту методом «народного тику»:

> sudo -u amandabackup amdump tivasyk.test
> sudo -u amandabackup tree ~/temp/
/home/tivasyk/temp/
├── amanda
│   ├── holding
│   └── state
│       ├── curinfo
│       │   └── localhost
│       │       └── _home_tivasyk_temp_data
│       │           └── info
│       ├── index
│       │   ├── localhost
│       │   │   └── _home_tivasyk_temp_data
│       │   │       ├── 20231225133659_0.header
│       │   │       └── 20231225133659_0-unsorted.gz
│       │   └── lock
│       └── log
│           ├── amdump.1 -> amdump.20231225133659
│           ├── amdump.20231225133659
│           ├── log -> log.20231225133659.0
│           ├── log.20231225133659.0
│           └── oldlog
├── backup
│   └── vtapes
│       ├── data -> slot1
│       ├── slot1
│       │   ├── 00000.MyData01
│       │   └── 00001.localhost._home_tivasyk_temp_data.0
│       ├── slot2
│       ├── slot3
│       └── state
└── data
    ├── bzip2.txt
    ├── gzip.txt
    └── tar.txt

щось відбулося. якийсь звіт про попередній прогін архівування можна переглянути за допомогою amreport tivasyk.test, журнал в читабельному (але не syslog) форматі лежить в …/amanda/state/log/log. судячи з розміру (122 кбайт), власне архів лежить ось тут:

> sudo -u amandabackup ls -lh /home/tivasyk/temp/backup/vtapes/data/
-rw------- 1 amandabackup amandabackup  32K гру 25 13:37 00000.MyData01
-rw------- 1 amandabackup amandabackup 122K гру 25 13:37 00001.localhost._home_tivasyk_temp_data.0
> sudo -u amandabackup file /home/tivasyk/temp/backup/vtapes/data/00001.localhost._home_tivasyk_temp_data.0
/home/tivasyk/temp/backup/vtapes/data/00001.localhost._home_tivasyk_temp_data.0: AMANDA

задля есперименту додам ще один файл до data/ і прожену архівування ще раз:

> man zip > /home/tivasyk/temp/data/zip.txt
> tree --du -h /home/tivasyk/temp/data/
[165K]  /home/tivasyk/temp/data
├── [ 17K]  bzip2.txt
├── [ 17K]  gzip.txt
├── [ 42K]  tar.txt
└── [ 86K]  zip.txt
> sudo -u amandabackup amdump tivasyk.test

що в теці …/bakup? посилання …backup/vtapes/data тепер вказує на slot2, найсвіжіший архів; розміри архівів ідентичні (підозріло, але може бути особливістю роботи віртуальних «плівок»).

[329K]  /home/tivasyk/temp/backup/
└── [325K]  vtapes
    ├── [   5]  data -> slot2
    ├── [158K]  slot1
    │   ├── [ 32K]  00000.MyData01
    │   └── [122K]  00001.localhost._home_tivasyk_temp_data.0
    ├── [158K]  slot2
    │   ├── [ 32K]  00000.MyData02
    │   └── [122K]  00001.localhost._home_tivasyk_temp_data.1
    ├── [4.0K]  slot3
    └── [1.1K]  state

є ще один вільний слот, не дам добру пропасти. цього разу додам до …/data/ щось масивніше — наприклад, pdf підказки «linux complete backup and recovery howto» від tldp.org (509 кб), і прожену архівування знову:

> wget https://tldp.org/HOWTO/pdf/Linux-Complete-Backup-and-Recovery-HOWTO.pdf -P /home/tivasyk/temp/data/ --
> tree --du -h /home/tivasyk/temp/data/
[674K]  data/
├── [ 17K]  bzip2.txt
├── [ 17K]  gzip.txt
├── [509K]  Linux-Complete-Backup-and-Recovery-HOWTO.pdf
├── [ 42K]  tar.txt
└── [ 86K]  zip.txt
> sudo -u amandabackup amdump tivasyk.test
...
> sudo -u amandabackup tree --du -h /home/tivasyk/temp/backup/
[993K]  /home/tivasyk/temp/backup
└── [989K]  vtapes
    ├── [   5]  data -> slot3
    ├── [158K]  slot1
    │   ├── [ 32K]  00000.MyData01
    │   └── [122K]  00001.localhost._home_tivasyk_temp_data.0
    ├── [158K]  slot2
    │   ├── [ 32K]  00000.MyData02
    │   └── [122K]  00001.localhost._home_tivasyk_temp_data.1
    ├── [668K]  slot3
    │   ├── [ 32K]  00000.MyData03
    │   └── [632K]  00001.localhost._home_tivasyk_temp_data.1
    └── [1.1K]  state

відновлення з архіву

цікаво, чому нумерування архівів поводиться так дивно: 0 -> 1 -> 1? відповідь, мабуть, є у звіті amreport, але для цього буде час пізніше. зараз цікаво, як відновлювати дані з архівів; імітую втрату даних:

> mkdir -p /home/tivasyk/temp/data.lost
> mv /home/tivasyk/temp/data/* /home/tivasyk/temp/data.lost/
> tree /home/tivasyk/temp/data*
/home/tivasyk/temp/data
/home/tivasyk/temp/data.lost
├── bzip2.txt
├── gzip.txt
├── Linux-Complete-Backup-and-Recovery-HOWTO.pdf
├── tar.txt
└── zip.txt

для відновлення за допомогою amrcover треба створити/виправити файл конфігурації /etc/amanda/amanda-client.conf (підказка):

> sudo -u amandabackup vim /etc/amanda/amanda-client.conf
# ----- >8 -----
index_server "localhost"
tapedev "changer"
auth "local"
# ----- 8< -----

пробую:

> sudo -u amandabackup amrecover tivasyk.test
amrecover: must be executed as the "root" user instead of the "amandabackup" user

а маєш. але логічно. друга спроба:

> sudo amrecover tivasyk.test
MRECOVER Version 3.5.2. Contacting server on localhost ...
220 katana AMANDA index server (3.5.2) ready.
Setting restore date to today (2023-12-25)
200 Working date set to 2023-12-25.
200 Config set to tivasyk.test.
501 Host katana is not in your disklist.
Trying host katana ...
501 Host katana is not in your disklist.
Trying host katana ...
501 Host katana is not in your disklist.
Use the sethost command to choose a host to recover

нас попереджали в підказці; але принаймні я в інтерактивній консолі amrecover, і є підказка, як діяти (але треба згодом поміняти amanda.conf).

amrecover> sethost localhost
200 Dump host set to localhost.
amrecover> help
...
amrecover> listdisk
200- List of disk for host localhost
201- /home/tivasyk/temp/data
200 List of disk for host localhost
amrecover> setdisk /home/tivasyk/temp/data
200 Disk set to /home/tivasyk/temp/data.
amrecover> ls
2023-12-25-15-27-53 zip.txt
2023-12-25-15-27-53 Linux-Complete-Backup-and-Recovery-HOWTO.pdf
2023-12-25-15-27-53 .
2023-12-25-13-36-59 tar.txt
2023-12-25-13-36-59 gzip.txt
2023-12-25-13-36-59 bzip2.txt
amrecover> add *
Added file /zip.txt
Added file /Linux-Complete-Backup-and-Recovery-HOWTO.pdf
Added file /tar.txt
Added file /gzip.txt
Added file /bzip2.txt
amrecover extract

Extracting files using tape drive changer on host katana.
The following tapes are needed: MyData01
                                MyData03

Extracting files using tape drive changer on host katana.
Load tape MyData01 now
Continue [?/Y/n/s/d]?] y
Restoring files into directory /home/tivasyk/temp/data
All existing files in /home/tivasyk/temp/data can be deleted
Continue [?/Y/n]? y

./bzip2.txt
./gzip.txt
./tar.txt
90 kb 
Extracting files using tape drive changer on host katana.
Load tape MyData03 now
Continue [?/Y/n/s/d]? y
./Linux-Complete-Backup-and-Recovery-HOWTO.pdf
./zip.txt
600 kb
amrecover> quit
200 Good bye.

що відбулось? знадобилося:

встановити ім’я хоста, як воно вказане в /etc/amanda/tivasyk.test/amanda.conf (sethost);
вибрати джерело архівування, як воно вказане в /etc/amanda/tivasyk.test/disklist (setdisk);
вибрати теки/файли для відновлення — в моєму випадку всі (add *);
почати відновлення, і підтвердити:
- завантаження віртуальної «плівки» mydata01;
- перезапис файлів на диску;
- завантаження віртуальної «плівки» mydata02.

перевірка списку файлів, відмінностей між відновленим і «втраченою» копією (data.lost), часу створення й прав доступу:

> tree --du -h /home/tivasyk/temp/data/
[674K]  /home/tivasyk/temp/data/
├── [ 17K]  bzip2.txt
├── [ 17K]  gzip.txt
├── [509K]  Linux-Complete-Backup-and-Recovery-HOWTO.pdf
├── [ 42K]  tar.txt
└── [ 86K]  zip.txt
> diff -qrN /home/tivasyk/temp/data /home/tivasyk/temp/data.lost && echo "ok"
ok
> ls -l /home/tivasyk/temp/data/
-rw-r--r-- 1 tivasyk tivasyk  18K гру 24 17:03 bzip2.txt
-rw-r--r-- 1 tivasyk tivasyk  18K гру 24 16:48 gzip.txt
-rw-r--r-- 1 tivasyk tivasyk 510K гру 14  2008 Linux-Complete-Backup-and-Recovery-HOWTO.pdf
-rw-r--r-- 1 tivasyk tivasyk  42K гру 24 16:48 tar.txt
-rw-r--r-- 1 tivasyk tivasyk  86K гру 25 15:06 zip.txt

все на місці!

(до змісту)

відновлення без конфігурації

все це чудово, але аманда має родзинку, яка й змусила мене зацікавитися цим додатком, на відміну від restic та borg: «прозорі» архіви, які можна використати для відновлення даних, навіть втрачено конфігурацію, всі файли стану (curinfo/, index/, log/), і навіть немає під рукою самої amanda. увага, смертельний номер: видалю знову теку даних, «випадково видалю» конфігурацію і стан amanda, і проведу ще один дослід:

> rm -rf /home/tivasyk/temp/data/*
> sudo mv /home/tivasyk/temp/amanda /home/tivasyk/temp/amanda.lost
> sudo mv /etc/amanda/tivasyk.test /etc/amanda/tivasyk.test.lost

задля інтересу спробую ще раз amrecover:

> sudo amrecover tivasyk.test
AMRECOVER Version 3.5.2. Contacting server on localhost ...
220 katana AMANDA index server (3.5.2) ready.
Setting restore date to today (2023-12-25)
200 Working date set to 2023-12-25.
501 Could not read config file for tivasyk.test!

катастрофа, все зламалось; але я ще маю доступ до самих файлів з архівами; що можна з них витягти? лінк data вказує на свіжу «плівку»; amanda починає кожну «плівку» блоком 32 кб зі службовою інформацією і підказкою для системного адміністратора в читабельному текстовому вигляді:

> sudo dd if=/home/tivasyk/temp/backup/vtapes/data/00001.localhost._home_tivasyk_temp_data.1 bs=32k count=1
AMANDA: SPLIT_FILE 20231225152753 localhost /home/tivasyk/temp/data  part 1/-1  lev 1 comp N program /usr/bin/tar
ORIGSIZE=600
NATIVE-CRC=9b5ae647:614400
CLIENT-CRC=9b5ae647:614400
SERVER-CRC=9b5ae647:614400
DLE=<<ENDDLE
<dle>
  <program>GNUTAR</program>
  <disk>/home/tivasyk/temp/data</disk>
  <level>1</level>
  <auth>local</auth>
  <record>YES</record>
  <index>YES</index>
  <datapath>AMANDA</datapath>
</dle>
ENDDLE
To restore, position tape at start of file and run:
        dd if=<tape> bs=32k skip=1 | /usr/bin/tar -xpGf - ...

це складніша операція, ніж штатне відновлення, тож варто використати тимчасову теку:

> tree /home/tivasyk/temp/backup/
/home/tivasyk/temp/backup/
└── vtapes
    ├── data -> slot3
    ├── slot1
    │   ├── 00000.MyData01
    │   └── 00001.localhost._home_tivasyk_temp_data.0
    ├── slot2
    │   ├── 00000.MyData02
    │   └── 00001.localhost._home_tivasyk_temp_data.1
    ├── slot3
    │   ├── 00000.MyData03
    │   └── 00001.localhost._home_tivasyk_temp_data.1
    └── state
> mkdir -p /home/tivasyk/temp/restore
> cd /home/tivasyk/temp/restore
> sudo dd if=/home/tivasyk/temp/backup/vtapes/data/00001.localhost._home_tivasyk_temp_data.1 bs=32k skip=1 | tar -tvf -
drwxr-xr-x tivasyk/tivasyk  86 2023-12-25 15:25 ./
-rw-r--r-- tivasyk/tivasyk 521383 2008-12-14 11:52 ./Linux-Complete-Backup-and-Recovery-HOWTO.pdf
-rw-r--r-- tivasyk/tivasyk  87580 2023-12-25 15:06 ./zip.txt

tar -tvf показує вміст архіву. решта файлів, очевидно, повинні бути в попердній «плівці». видобування потребуватиме уваги, бо amanda автоматично планує повні і інкрементні архіви, і далеко не завжди останній архів міститиме все, що треба; amrecover приховує ці складнощі, та якщо працювати безпосередньо з архівами — доведеться знайти потрібний повний архів і видобути решту по порядку, — але принаймні це можливо.

(до змісту)

стиснення

стиснення можна відносно легко налаштувати в файлі конфігурації. новий експеримент: спробую архівувати теку ~/Ігри (5,5 гб) зі стисненням. не забути відновити «втрачену» конфігурацію і теки стану:

> sudo mv /etc/amanda/tivasyk.test.lost /etc/amanda/tivasyk.test
> sudo mv /home/tivasyk/temp/amanda.lost /home/tivasyk/amanda

мені знадобиться значно більше «плівок», і більшого розміру:

> sudo -u amandabackup vim /etc/amanda/tivasyk.test/amanda.conf
# ----- >8 -----
define tapetype TEST-TAPE {
    length 1024 mbytes
}
# ----- 8< -----

для стиснення на стороні клієнта (гратиме роль для віддаленого архівування) додаю ще одну секцію dumptype:

# ----- >8 -----
define dumptype compressed-gnutar-local {
    auth "local"
    compress client best
    program "GNUTAR"
}
# ----- 8< -----

«розумніше» налаштування чейнжера: кількість «плівок» (10) і автоматичне створення тек для них:

# ----- >8 -----
define changer "archive" {
    tpchanger "chg-disk:/home/tivasyk/temp/backup/vtapes"
    property "num-slot" "10"
    property "auto-create-slot" "yes"
}
# ----- 8< -----

основна частина конфігурації amanda.conf (документація, особливо зважити на tapecycle, dumpcycle):

tpchanger "archive"
tapetype "TEST-TAPE"
labelstr "Games-[0-9][0-9]"
autolabel "Games-%%" EMPTY VOLUME_ERROR
tapecycle 8
dumpcycle 7 days
amrecover_changer "archive"

в disklist додаю теку для стиснення:

> sudo vim /etc/amanda/tivasyk.test/disklist
# ----- >8 -----
localhost /home/tivasyk/temp/data simple-gnutar-local
localhost /home/tivasyk/Ігри compressed-gnutar-local
# ----- 8< -----

перевірка конфігурації:

> sudo -u amandabackup amcheck tivasyk.test
Amanda Tape Server Host Check
-----------------------------
NOTE: Holding disk '/home/tivasyk/temp/amanda/holding': 34680832 KB disk space available, using 102400 KB as requested
slot 4: contains an empty volume
Will write label 'Games-01' to new volume in slot 4.
NOTE: skipping tape-writable test
NOTE: info dir '/home/tivasyk/temp/amanda/state/curinfo/localhost/_home_tivasyk_Ігри' does not exist
      it will be created on the next run
NOTE: index dir '/home/tivasyk/temp/amanda/state/index/localhost/_home_tivasyk_Ігри' does not exist
      it will be created on the next run
Server check took 0.180 seconds
Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 2.150 seconds.  0 problems found.
(brought to you by Amanda 3.5.2)

цікаво зауважити на майбутнє, що така зміна конфігурації «на льоту», між двома прогонами, не бентежить аманду. час запускати архівування — з рівнем стиснення best це може зайняти чимало часу навіть для 5 гб (а мені треба архівувати під 500 гб на owncloud’і…):

> sudo -u amandabackup amdump tivasyk.test ; echo $?
4

овва, впіймав помилку: 4 (a dle failed, документація); що трапилось? дивлюся журнали в /home/tivasyk/temp/amanda/state/log/… і в amdump.1 бачу таке:

planner: FAILED localhost "/home/tivasyk/Ігри" 20231226172806 0 ["dump estimate ( 2831940 KB ) is larger than available tape space ( 1048576 KB ),  but cannot incremental dump new disk"]

amanda каже, що доступний для архівування простір — 1 гб (available tape space), а оцінка необхідного простору — 3 гб. але 1 гб — це розмір однієї «плівки»… я ж очікував, що програма, заповнивши одну, автоматично писатиме на наступну? здається, час знову читати документацію… і відповідь: tape spanning, але для віртуальних «плівок» ця функція має бути включена по замовчуванню; чому ж не працює? халепа, тут навіть я мушу визнати, що конфігурація вельми заплутана… в підсумку опція runtapes (вказує кількість плівок, які amanda може заповнити за прогін, довільно вибрав 5) допомогла:

# ----- >8 -----
...
amrecover_changer "archive"
runtapes 5
# ----- 8< -----

тепер наче працює:

> sudo -u amandabackup amdump tivasyk.test || echo "error"
> sudo -u amandabackup amreport tivasyk.test

зі звіту amreport (підказка з читання) видно, що:

архів зайняв 4,4 гб на п’яти «плівках»;
час прогону — 9 хв;
середній розмір після стиснення — 80%.

(до змісту)

шифрування

amanda пропонує три варіанти шифрування; найнадійнішим видається асиметричне openssl (документація); його головний недолік, нмсд, випливає з його ж головної переваги: приватний ключ треба якось зберігати так, щоби ніхто не отримав до нього доступу, але водночас він має бути під рукою, коли знадобиться відновити щось із архівів. якщо це комусь здається простим — рано чи пізно на вас чекатиме сюрприз…

але менше з тим, генеруємо ключі openssl для шифрування; для випроби я все роблю на локальній машині — але в реальному житті ніколи так не варто робити! всі ключі шифрування (vpn тощо) бажано генерувати на окремій машині (не тій, де використовуватиметься публічний ключ!), доступ до котрої обмежений (наприклад, вона завжди вимкнена):

# ключ rsa1024 без пароля!
> sudo -u amandabackup openssl genrsa -out ~amandabackup/backup-privkey.pem 2048 
> sudo -u amandabackup openssl rsa -in ~amandabackup/backup-privkey.pem -pubout -out ~amandabackup/backup-pubkey.pem
> sudo -u amandabackup ls -l ~amandabackup/
...
-rw------- 1 amandabackup amandabackup 1704 гру 26 20:05 backup-privkey.pem
-rw-r--r-- 1 amandabackup amandabackup  451 гру 26 20:06 backup-pubkey.pem
...

тут ~amandabackup вказує на домашню теку користувача amandabackup; за замовчуванням це /var/lib/amanda/. конфігурація шифрування в amanda.conf:

> sudo vim /etc/amanda/tivasyk.test/amanda.conf
# ----- >8 -----
define dumptype compressed-encrypted-gnutar-local {
    allow-split true
    auth "local"
    program "GNUTAR"
    compress client fast
    encrypt server
    server_encrypt "/usr/bin/amcrypt-ossl-asym"
    server_decrypt_option "-d"
}
# ----- 8< -----

не хочу більше архівувати 5 гб, тому видалю один рядок з disklist, і вкажу новий dumptype для тестової теки data (заодно випробую, чи можна просто тут замінити localhost на назву машини, /etc/hosts має бути в порядку):

> sudo vim /etc/amanda/tivasyk.test/disklist
# ----- >8 -----
katana /home/tivasyk/temp/data compressed-encrypted-gnutar-local
# ----- 8< -----

перевірка конфігурації, прогін архівування, перегляд звіту:

> sudo -u amandabackup amcheck tivasyk.test
> sudo -u amandabackup amdump tivasyk.test
> sudo -u amandabackup amreport tivasyk.test

архів скинуто на «плівку» Games-06 (на теку вказує посилання backup/vtapes/data):

> sudo dd if=/home/tivasyk/temp/backup/vtapes/data/00001.katana._home_tivasyk_temp_data.0 bs=32k count=1
...
To restore, position tape at start of file and run:
        dd if=<tape> bs=32k skip=1 | /usr/bin/amcrypt-ossl-asym -d | /usr/bin/gzip -dc | /usr/bin/tar -xpGf - ...

спробуємо (конструкція з sh -c дозволяє запускати ввесь ланцюжок від root’а):

> sudo sh -c 'dd if=/home/tivasyk/temp/backup/vtapes/data//00001.katana._home_tivasyk_temp_data.0 bs=32k skip=1 | /usr/bin/amcrypt-ossl-asym -d | /usr/bin/gzip -dc | /usr/bin/tar -tvf -'
...
drwxr-xr-x tivasyk/tivasyk  86 2023-12-25 15:59 ./
-rw-r--r-- tivasyk/tivasyk 521383 2008-12-14 11:52 ./Linux-Complete-Backup-and-Recovery-HOWTO.pdf
15+1 записів прочитано
15+1 записів записано
скопійовано 515896 байтів (516 kB, 504 KiB), 0,0319564 s, 16,1 MB/s
-rw-r--r-- tivasyk/tivasyk  17474 2023-12-24 17:03 ./bzip2.txt
-rw-r--r-- tivasyk/tivasyk  17473 2023-12-24 16:48 ./gzip.txt
-rw-r--r-- tivasyk/tivasyk  42645 2023-12-24 16:48 ./tar.txt
-rw-r--r-- tivasyk/tivasyk  87580 2023-12-25 15:06 ./zip.txt

gzip: stdin: decompression OK, trailing garbage ignored

чудово, все розшифрувалося, видно перелік файлів у архіві.

(до змісту)

віддалене архівування

останній есперимент із amanda — архівування даних на сервер з віддалених машин в локальний мережі; для цього amanda використовує ssh (з ключами ssh для amandabackup). для тесту сервером буде лептоп (katana.lan), а клієнтом — файловий сервер на hp microserver (micro.lan), хоча згодом саме micro буде сервером бекапів (багато дешевого місця) і staging’ом для вивантаження шифрованих архівів offsite.

найперше — встановити amanda на клієнті (micro.lan, debian 10 (buster), адреси ip приховую):

> grep micro.lan /etc/hosts
192.168.x.x     micro micro.lan
> ssh tivasyk@micro.lan
...
micro.lan> sudo apt update && sudo apt upgrade
micro.lan> apt search amanda
...
amanda-client/oldoldstable 1:3.5.1-2+deb10u2 amd64
  Advanced Maryland Automatic Network Disk Archiver (Client)
amanda-common/oldoldstable 1:3.5.1-2+deb10u2 amd64
  Advanced Maryland Automatic Network Disk Archiver (Libs)
amanda-server/oldoldstable 1:3.5.1-2+deb10u2 amd64
  Advanced Maryland Automatic Network Disk Archiver (Server)

зараз для тесту мені потрібен лише клієнтський додаток:

micro.lan> sudo apt install amanda-client

документація на офсайті… вельми стара, плутана, і не завжди відповідає сучасній дісності. зокрема, налаштування демона (amandad) на стороні клієнта в документації… покладається на зміни в xinetd, а комунікація з сервером використовує bsdtcp — це минуле століття, сьогодні цього не треба (а якщо чомусь треба — див. підказку з налаштування сервісу systemd замість редагування xinetd); для комунікації по ssh це, здається, не потрібно, але налаштування amanda-server (документація) та amanda-client (документація) на debian має свої особливості: використано службовий профіль backup (а не amandabackup) з домашньою текою /var/backups/ (а не /var/lib/amandabackup/):

micro.lan> sudo grep backup /etc/passwd
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin

встановлюю bash як оболонку, а також тимчасово активую/змінюю пароль профілю backup:

micro.lan> sudo chsh -s /usr/bin/bash backup
micro.lan> sudo passwd backup

на жаль, вибір /var/backups/ як домашньої теки для сервісного профілю і місця зберігання копій важливих файлів у debian — вельми немудре, але доведеться давати собі раду, бо туди треба буде закинути ключ ssh з сервера:

micro.lan> sudo mkdir /var/backups/.ssh
micro.lan> sudo chown backup:root /var/backups/.ssh

створюю ключ ssh для amanda на сервері (katana.lan), і перекидую на micro.lan:

> sudo -u amandabackup ssh-keygen -t rsa -C "SSH key for Amanda backup of clients"
> sudo -u amandabackup ls -la ~amandabackup/.ssh/
-rw------- 1 amandabackup amandabackup 2635 гру 27 10:37 id_rsa
-rw-r--r-- 1 amandabackup amandabackup  596 гру 27 10:37 id_rsa.pub
> sudo -u amandabackup ssh-copy-id -i ~amandabackup/.ssh/id_rsa backup@micro.lan

перевірка: чи можна з профілю amanda залогінитися як backup на micro.lan?

> sudo -u amandabackup ssh backup@micro.lan 'hostname; id'
micro
uid=34(backup) gid=34(backup) groups=34(backup),6(disk),26(tape)

що працює. тепер можна (опційно) видалити пароль для профілю backup — логін через ssh працюватиме. черга конфігурації amanda на «сервері» (katana), додаю новий dumptype, ключові опції — auth, ssh-keys (файл ключа ssh), client-username (профіль на стороні клієнта):

> sudo vim /etc/amanda/tivasyk.test/amanda.conf
# ----- >8 -----
define dumptype compressed-encrypted-gnutar-ssh {
    auth "ssh"
    ssh-keys "/var/lib/amanda/.ssh/id_rsa"
    client-username "backup"
    program "GNUTAR"
    compress client fast
    encrypt server
    server_encrypt "/usr/bin/amcrypt-ossl-asym"
    server_decrypt_option "-d"
}
# ----- 8< -----

додаю рядок до tivasyk.test/disklist — спробую архівувати /etc на клієнті:

> sudo vim /etc/amanda/tivasyk.test/disklist
# ----- >8 -----
micro.lan /etc compressed-encrypted-gnutar-ssh
# ----- 8< -----

перевірка конфігурації для клієнта:

> sudo -u amandabackup amcheck tivasyk.test -c micro.lan
Amanda Backup Client Hosts Check
--------------------------------
HOST micro.lan ERROR: security file '/etc/amanda-security.conf' do not allow to run '/usr/bin/tar' as root for 'runtar:gnutar_path'
Client check: 1 host checked in 2.391 seconds.  1 problem found.
(brought to you by Amanda 3.5.2)

люблю зрозумілі повідомлення про помилки. перевірка на micro.lan:

micro.lan> sudo less /etc/amanda-security.conf
# Uncomment and edit the following lines to let Amanda to  #
# use customized system commands.  If multiple PATH is     #
# necessary, please put them in different lines.           #
...
#runtar:gnutar_path=/bin/tar

гаразд, треба розкоментувати один рядок. зроблено, друга спроба теж не вдалась — поремонтувалося, коли замінив /bin/tar на /usr/bin/tar (попри те, що лінк /bin/tar присутній; дивно):

> sudo -u amandabackup amcheck tivasyk.test -c micro.lan
Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 2.308 seconds.  0 problems found.
(brought to you by Amanda 3.5.2)

спроба архівування:

> sudo -u amandabackup amdump tivasyk.test; echo "$?"
2

код завершення 2: «a dle give strange message». наскільки я зрозумів, трохи поколупавши журнали, це спричинено попередженням від openssl про те, що openssl-rsautl застарів і треба використовувати pkeyutl, але amanda про це не знає. треба шукати, як це виправити (бо ненульовий код виходу завадить мені моніторити бекапи через healthchecks.io), але попри це — amanda запакувала:

> sudo tree /home/tivasyk/temp/backup/vtapes/data/
/home/tivasyk/temp/backup/vtapes/data/
├── 00000.Games-07
├── 00001.katana._home_tivasyk_temp_data.1
└── 00002.micro.lan._etc.0
> sudo sh -c 'dd if=/home/tivasyk/temp/backup/vtapes/data/00002.micro.lan._etc.0 bs=32k skip=1 | /usr/bin/amcrypt-ossl-asym -d | /usr/bin/gzip -dc | /usr/bin/tar -tvf -'
...
-rw-r--r-- root/root        212 2019-11-02 14:16 ./terminfo/README
...
-rw-r--r-- root/root       2389 2019-06-15 12:41 ./vim/vimrc
-rw-r--r-- root/root        662 2019-06-15 12:41 ./vim/vimrc.tiny
...

на цьому поки що досить розваг із амандою; попередній висновок: інструмент сподобався відносною (як на мій адмінський розум) простотою і надійністю, але є нюанси, які треба вивчати й враховувати.

(до змісту)

інші опції

ось декілька інших програм, які я побачив, але з різних причин не пробував (найчастіше — «непрозоре» сховище бекапів); можливо, випробую колись за іншим разом:

restic (документація) — цікавий інструмент, простий у використанні, але ховає «під капотом» багато складнощів: підтримує різні сховища — від локального зберігання до хмар amazon, microsoft і google, має обов’язкове інтегроване шифрування. але не має стиснення (хоча в новіших версіях, здається, додали zstd?), і має «непрозоре» сховище — бекапи доступні лише через інтерфейс (cli) restic, це (не) трохи напружує.
borgbackup (документація) — ще один дуже цікавий варіант, подібний до restic; підтримує дедуплікацію на рівні блоків (менші розміри ), стиснення; шифрування, здається, необов’язкове; зручний розвинений інтерфейс cli; з недоліків: блокова дедуплікація потребує встановленого клієнта на обох кінцях, складність «під капотом», «непрозоре» сховище бекапів (доступ до змісту й файлів лише через інтерфейс borg).

(до змісту)

далі буде…

↖