Schnapps mazání importovaných obrazů

JardaB · September 9, 2019, 7:21am

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:~#

RomanHK · September 9, 2019, 7:55am

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

schnapps cleanup --compare

JardaB · September 9, 2019, 10:58am

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:~#

RomanHK · September 9, 2019, 11:55am

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.:

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'

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).
Proveďte zálohu.

Nones · September 9, 2019, 12:14pm

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?

RomanHK · September 9, 2019, 12:45pm

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.

Nones · September 9, 2019, 1:08pm

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

JardaB · September 9, 2019, 3:12pm

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)

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

RomanHK · September 9, 2019, 7:31pm

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á.

ljelinek · September 10, 2019, 7:46am

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.

Nones · September 10, 2019, 8:34am

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

JardaB · September 10, 2019, 2:56pm

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"

RomanHK · September 10, 2019, 4:36pm

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

JardaB · September 10, 2019, 5:15pm

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

díky za trpělivost