Schnapps mazání importovaných obrazů

Po základním oživení routeru instalací systému na SSD jsem importoval dva záložní odložené schnapps obrazy.
Systém mi nyní pracuje regulérně, ale nemohu smazat první dva obrazy

root@turris:~# schnapps list
    # | Type      | Size        | Date                        | Description
------+-----------+-------------+-----------------------------+------------------------------------
  @18 | single    |             | 2019-08-09 14:47:15 +0200   | aa
  @23 | single    |             | 2019-08-09 14:47:15 +0200   | aa
    4 | single    |    10.16MiB | 2019-09-05 17:44:31 +0200   | 3.11.5
   17 | single    |    65.12MiB | 2019-09-06 09:54:32 +0200   | 3.11.5 II
   24 | single    |    64.55MiB | 2019-09-06 10:38:49 +0200   | tovární
   35 | single    |    13.11MiB | 2019-09-06 21:50:37 +0200   | AdBlock
   54 | single    |    16.00KiB | 2019-09-09 09:12:25 +0200   | QoS and graphs
root@turris:~# schnapps delete 18 23
WARNING: Snapshot number 18 does not exists!
WARNING: Snapshot number 23 does not exists!
root@turris:~#

Vyzkoušejte tento příkaz (ten by to měl vyčistit a zkorigovat):

schnapps cleanup --compare
root@turris:~# schnapps cleanup --compare
Searching for snapshots without any change.
This can take a while, please be patient.

 * checking snaphot 17...
 * checking snaphot 24...
 * checking snaphot 35...
 * checking snaphot 54...
 * checking snaphot 55...
   - Snapshot 54 deleted.
 * checking snaphot 56...
Looking for old snapshots...
root@turris:~# schnapps list
    # | Type      | Size        | Date                        | Description
------+-----------+-------------+-----------------------------+------------------------------------
  @18 | single    |             | 2019-08-09 14:47:15 +0200   | aa
  @23 | single    |             | 2019-08-09 14:47:15 +0200   | aa
    4 | single    |    10.16MiB | 2019-09-05 17:44:31 +0200   | 3.11.5
   17 | single    |    65.12MiB | 2019-09-06 09:54:32 +0200   | 3.11.5 II
   24 | single    |    64.55MiB | 2019-09-06 10:38:49 +0200   | tovární
   35 | single    |    13.11MiB | 2019-09-06 21:50:37 +0200   | AdBlock
   55 | pre       |    12.51MiB | 2019-09-09 09:48:20 +0200   | Automatic pre-update snapshot
   56 | post      |    12.14MiB | 2019-09-09 09:48:25 +0200   | Automatic post-update snapshot
root@turris:~#

Tak pak to vidím na úplný výmaz schnapps a následně novou čistou zálohu (možná to bude i nejlepší, pač máte systém na SSD), tzn.:

  1. Editujte soubor /etc/config/schnapps a nechte pouze sekci s výchozími hodnotami:
config keep 'keep'
        option max_single '-1'
        option max_time '5'
        option max_updater '5'
        option max_rollback '3'
  1. Smažte vše ve složce uložiště schnapps, ale to nevím, kam se to přesně ukládá (asi tady: /mnt/.snapshots).

  2. Proveďte zálohu.

Já bych se podíval na obsah souboru, který popisuje, co je v kterém snapshotu.
Nachází se v rootu filesystému … název nevím, nejsem teď u routeru.

Koresponduje to se skutečnými snapshoty?

S velkou pravděpodobností v tom bude pěknej chaos, pač @JardaB prováděl obnovu ze snapshotu pod jménem “aa” a má vadnou eMMC, tudíž na prázdný SSD, který je teď boot system.

Chaos … to si dokážu představit.

Ale když se zadá příkaz “schnapps list”, tak ten jen vypisuje obsah toho souboru, nekontroluje, zda-li vlastní snapshot existuje nebo ne.

Teď jsem našel na Turrisím GITLABu, že ten indexový soubor má příponu .info

Tak v něm lze udělat příslušné korekce toho, co se jen vypisuje, ale nemá to skutečný obraz v existujícím snapshotu.

Editujeme samozřejmě opatrně a obezřetně … myslíme na to, co děláme :slight_smile:

  • Tak soubor s příponou .info nenalezen.

  • Ve složce ./mnt/snapshots a ./mnt/remote-snapshots nic není … jsou prázdné … smazání obou adresářů nepřineslo změnu.

  • Soubor /etc/config/schnapps vypadá origo takto

(z neznámého důvodu mi textová forma hází v některých řádcích velká písmena – proto dávám obrázek)

image

  • Hledání čeholi (program mc … zobrazené skrytých souborů) s názvem snap* nebo schnapps mne k seznamu (indexu) zobrazovaných záloh nedovedlo.

  • Jen pro jistotu dávám přípojné body

Tak to by mě taky tedy zajimalo (kde je ta “databaze”), odkud bere informace o zálohách. Ještě je jedno místo (/etc/schnapps/), kde mám ale pouze další složku “rollback.d”.

Já bohužel (nebo bohudík pro mě) nepoužívám schnapps, docela mě dalo práci to zakázat, takže už mě nic nenapadá.

Ta “databáze” jsou soubory *.info, které ale běžně nejsou vidět, protože jsou na hlavním svazku souborového systému btrfs a ten standardně není nikam připojen. Jako kořenový souborový systém je připojen podsvazek (subvolume) s označením “@” (viz výpis příkazu mount).

Příkaz schnapps si pro svou činnost vždycky nejdřív připojí hlavní svazek (do /mnt/.snapshots) a po práci ho zase odpojí. Lze ho připojit pomocí mount /dev/mmcblk0p1 -o subvol=/ /mnt/adresar (adresář pro připojení musí samozřejmě existovat, ale je jedno, kde je) a pak s ním pracovat.

Kromě souborů *.info (které lze na vlastní nebezpečí ručně upravovat a případně i mazat) jsou tam i adresáře jednotlivých snímků a lze s nimi pracovat klasicky pomocí příkazu btrfs. Například informace o snímku č. 30 se získají příkazem btrfs subvolume show @30.

3 Likes

Jo, to přesně jsem měl na mysli … díky za upřesnění :+1:

root@turris:~#  mount /dev/mmcblk0p1 -o subvol=/ /mnt/snap
root@turris:~# mc

Podle toho co vidím se v tom vůbec nevyznám … zejména nesedí data vytvoření souborů a jejich počty schnapps vidí 2+6 obrazů mezi 8.8.-9.9.219

  • v přimountovaném adresáři je jich 14 s datumy od 29.12.2018 do 11.srpna

To asi vidím soubory v původní systémové paměti a ne na nynějším systémovém ssd disku ??

níže obsah sedmi info souborů

647
TYPE="rollback"
DESCRIPTION="Rollback to snapshot 528"
ROLL_TO=528
CREATED="2018-12-29 21:07:04 +0100" 

639
TYPE="post"
DESCRIPTION="Automatic post-update snapshot"
CREATED="2019-06-21 10:45:12 +0200" 

642
TYPE="single"
DESCRIPTION="User created snapshot"
CREATED="2019-06-25 13:36:51 +0200" 


643
TYPE="single"
DESCRIPTION="AAA"
CREATED="2019-06-25 20:23:29 +0200" 
.
.
.
660
TYPE="rollback"
DESCRIPTION="Rollback to snapshot 659"
ROLL_TO=659
CREATED="2019-08-11 07:29:43 +0000" 

661
TYPE="rollback"
DESCRIPTION="Rollback to snapshot factory"
ROLL_TO=factory
CREATED="2019-08-11 07:58:26 +0000" 

662
TYPE="rollback"
DESCRIPTION="Rollback to snapshot factory"
ROLL_TO=factory
CREATED="2019-08-11 08:06:24 +0000"

Možná mount bude vypadat obdobně, ale bude naveden na SSD tzn. ve vašem případě /dev/sda1

mount /dev/sda1 -o subvol=/ /mnt/snap
2 Likes

Jo … je to tak

a výsledek po smazání dvou @*.info souborů

No a jeď jen správně “ocertifikovat” ucollect a budu bez chyby :slight_smile:

díky za trpělivost

1 Like