restic forget a prune: retenční pravidla na S3

Retenční pravidla v resticu jsou dva příkazy s různou úlohou a velmi odlišnou cenou. restic forget je levný: přečte tvoje pravidlo, rozhodne, které záznamy snapshotů smazat, a smaže je - pár drobných objektů. restic prune je drahý: zjistí, která data už žádný zbývající snapshot nepotřebuje, pak maže celé pack soubory a přepisuje ty využité jen zčásti, což na S3 znamená stahovat a nahrávat skutečná data a přitom držet exkluzivní zámek repozitáře. Rozumné uspořádání pro většinu serverů je forget po každé záloze, prune jednou týdně s --max-unused ponechaným na výchozích 5 % nebo zvýšeným a obojí spouštěné systemd timery s --retry-lock, aby na sebe počkaly a nepadaly. Zbytek článku jsou detaily, díky kterým to funguje: co přesně počítají přepínače --keep-*, proč snapshoty přežijí pravidlo, které je podle tebe mělo smazat, kolik stojí prune a co dělat, když repozitář hlásí, že je zamčený.

Tohle je hluboký ponor do jednoho tématu. Založení repozitáře, zálohování souborů a databází, kontrola a obnova jsou v článku restic zálohy na S3; kolik místa historie zabere, najdeš v článku dimenzování úložiště S3 a pravidlo 3-2-1.

Co forget skutečně počítá#

Přepínače --keep-* se snadno čtou a snadno špatně chápou. Pravidlo za všemi je stejné: restic seřadí snapshoty od nejnovějšího, rozdělí čas na intervaly dané velikosti (hodina, den, týden, měsíc, rok) a ponechá nejnovější snapshot v každém z n posledních intervalů, které nějaký snapshot obsahují.

Z toho plynou tři důsledky a každý někoho překvapí.

• Počítají se intervaly se snapshoty, ne kalendářní jednotky. --keep-daily 7 ponechá jeden snapshot z každého z posledních sedmi dnů, kdy záloha běžela. Pokud byl server čtrnáct dní vypnutý, sedm ponechaných dnů sahá tři týdny zpět. Je to záměr: záloha, která tiše přestane běžet, pomalu nesmaže zbytek tvé historie.
• Počítá se jen nejnovější snapshot v intervalu. Při zálohách každých šest hodin a --keep-daily 7 ponecháš poslední snapshot každého dne, ne první, a ostatní tři z každého dne se smažou, pokud je neponechá jiné pravidlo.
• Pravidla tvoří sjednocení. Snapshot se ponechá, pokud ho ponechá kterékoli pravidlo. Nejnovější snapshot je obvykle zároveň denní, týdenní i měsíční, takže --keep-daily 7 --keep-weekly 4 --keep-monthly 6 ponechá zhruba patnáct snapshotů, ne sedmnáct.

Intervaly vycházejí z vlastního časového razítka snapshotu v místním časovém pásmu stroje, na kterém běží forget. Server v UTC, který zálohuje ve 23:30, a notebook v UTC+4 čtoucí stejný repozitář povedou hranice dnů na různých místech. Ze stejného důvodu spouštěj forget ze stroje, který zálohuje, ne z pracovní stanice.

keep-within a jeho varianty

--keep-within 30d ponechá každý snapshot novější než zadaná doba. Doby kombinují roky, měsíce, dny a hodiny: 1y6m, 14d, 2d12h. Past je v referenčním bodu: doba se měří od nejnovějšího snapshotu ve skupině, ne od dneška. Pokud zálohy přestaly před třemi měsíci, --keep-within 30d stále ponechá třicet dnů před poslední zálohou - stejné ochranné chování jako u počtu intervalů.

restic 0.13 přidal --keep-within-hourly, --keep-within-daily, --keep-within-weekly, --keep-within-monthly a --keep-within-yearly. Spojují obě myšlenky: jeden snapshot na interval, pro každý interval uvnitř zadané doby. --keep-within-daily 7d --keep-within-weekly 1m --keep-within-monthly 1y se čte přirozeněji než počítání intervalů a chová se lépe, když se změní rozvrh záloh, protože době je jedno, kolik běhů se do ní vešlo.

Volba pravidla#

Správné pravidlo neexistuje, jen kompromis mezi tím, jak daleko zpět se můžeš vrátit, a kolik toho ukládáš. Rozhodují dvě otázky. Jak dlouho může problém zůstat nepovšimnutý? Poškozený soubor světa nebo smazanou tabulku často objevíš až za dny, takže denní historie kratší než týden je optimistická. A jak daleko zpět bys kdy obnovoval? Herní server z doby před jedenácti měsíci neobnovuje téměř nikdo, ale databázi z minulého čtvrtletí může někdo potřebovat kvůli účetnímu dotazu.

Cena úložiště u delšího pravidla je menší, než lidé čekají, protože každý další snapshot přidá jen chunky, které se změnily oproti sousedovi. Měsíční snapshot, který je půl roku jedinečný, stojí jen to, co se v onom měsíci změnilo, ne plnou kopii. Článek o dimenzování to propočítává; stručně řečeno, přechod ze 7 denních snapshotů na 7 denních plus 6 měsíčních repozitář málokdy zdvojnásobí a často přidá třetinu.

Cena, která s délkou pravidla roste, je čas. Každý snapshot jsou metadata, která musí forget, prune a check přečíst, a pravidlo --keep-hourly 720 na vytíženém serveru zpomalí každý údržbový běh za velmi malý užitek. Historii ředěj, jak stárne: po hodinách den, po dnech týdny, dál po měsících.

Připnutí snapshotů tagy

--keep-tag je únikový východ. Označ snapshot tagem a žádné časové pravidlo ho neodstraní:

$ restic tag --add keep-forever --tag nightly a81d0b37$ restic forget --keep-daily 7 --keep-weekly 4 --keep-tag keep-forever --prune

restic tag umí také --remove a --set. Tagování přepisuje záznam snapshotu, takže snapshot dostane nové ID; to staré zmizí z restic snapshots. Použij to před velkou aktualizací hry, migrací databáze nebo čímkoli, co bys příští měsíc mohl chtít vrátit, a tag odstraň, až si budeš jistý, že to nebude potřeba.

Pamatuj, že --keep-tag musí být u každého spuštění forget. Jednorázový příkaz bez něj, napsaný ve spěchu, smaže připnuté snapshoty jako každé jiné.

Skupiny: proč některé snapshoty nikdy nezmizí#

forget nepoužije tvoje pravidlo na celý repozitář najednou. Nejdřív rozdělí snapshoty do skupin a pravidlo uplatní na každou skupinu zvlášť. Výchozí je --group-by host,paths: snapshoty ze stejného hostname se stejným seznamem zálohovaných cest tvoří jednu skupinu.

Tohle výchozí chování je většinou správné - databázové dumpy a souborové zálohy jednoho serveru si každé drží svých sedm dnů - ale způsobuje nejčastější stížnost na retenci: snapshoty, které nikdy nevyprší. Každá z těchto situací založí novou skupinu a stará skupina si své poslední snapshoty drží navždy, protože jsou ve své skupině vždy nejnovější:

• Změnil jsi zálohované cesty. Přidání /etc k úloze, která zálohovala /srv, vytvoří novou skupinu. Stará skupina jen s /srv si ponechá svých posledních 7 denních, 4 týdenní a 6 měsíčních snapshotů donekonečna.
• Změnilo se hostname. Kontejnery dostávají při každém přebudování nové náhodné hostname a přeinstalovaný stroj nemusí dostat své staré jméno zpět. Každá záloha z nového hostname je nová skupina. Oprav to při zálohování pomocí restic backup --host web-01, což zapíše pevné jméno bez ohledu na skutečné.
• Cesty jsou zapsané jinak. restic ukládá absolutní cesty, takže /srv/app a /srv/app/ se normalizují na totéž, ale cesta přes symlink a její cíl ne.

Vidíš to ve výstupu s dry-run, který vypisuje jeden blok na skupinu:

Applying Policy: keep 7 daily, 4 weekly, 6 monthly snapshotssnapshots for (host [web-01], paths [/srv]):keep 6 snapshots:...snapshots for (host [web-01], paths [/etc /srv]):keep 14 snapshots:...

Skupina, kterou už nezálohuješ, se tu objeví s celou historií ponechanou. Odstraň ji záměrně tak, že ji vybereš a použiješ krátké pravidlo:

$ restic forget --host web-01 --path /srv --keep-last 1 --dry-run

Alternativou je změnit seskupování. --group-by host bere všechny cesty z jednoho hostitele jako jednu historii, což přežije změny cest, ale slije souborové a databázové snapshoty do jedné časové osy - s --keep-daily 7 by z dvojice z každého dne přežil jen ten novější. --group-by host,tags je nejčistší volba, když má každá úloha svůj tag (files, mysql, postgres), protože historii pak určuje tag a cesty se mohou volně měnit. --group-by '' seskupování úplně vypne, což na repozitáři s více než jednou úlohou téměř nikdy nechceš.

--host, --path a --tag u forget jsou filtry, ne seskupení: omezují, které snapshoty příkaz vůbec uvažuje. restic forget --tag mysql --keep-daily 30 použije třicetidenní pravidlo na databázové snapshoty a všechny ostatní nechá být, takže jeden repozitář může mít pro každou úlohu jiné pravidlo.

Bezpečné spouštění forget#

Dry run si přečti poprvé a pokaždé, když pravidlo měníš:

$ restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run

Výstup vypisuje pro každou skupinu snapshoty k ponechání s důvodem, proč se ponechávají (daily snapshot, weekly snapshot, last snapshot a tak dále), a snapshoty k odstranění. Pokud seznam k odstranění obsahuje něco, co jsi chtěl ponechat, je to téměř vždy problém seskupení nebo hranice intervalu v jiném časovém pásmu a obojí je vidět ve sloupci s důvody.

restic 0.16 a novější odmítnou spustit pravidlo, které by odstranilo všechny snapshoty ve skupině; to vyžaduje --unsafe-allow-remove-all. forget úplně bez pravidla neodstraní nic. Obojí jsou pojistky proti shellovému skriptu, který sestaví příkaz z prázdné proměnné.

forget přijímá i přímo ID snapshotů - restic forget a81d0b37 c5e9f210 - což je úhledný způsob, jak odstranit známý vadný snapshot, třeba pořízený během selhávajícího dumpu databáze, dřív než znečistí měsíční slot.

Co dělá prune a které volby ho řídí#

forget maže jen záznamy snapshotů. Data zůstanou, dokud neběží prune. Prune pracuje ve fázích:

1. Přečte všechny zbývající snapshoty a sestaví množinu chunků, které se pořád používají.
2. Roztřídí každý pack soubor: plně využitý, plně nevyužitý nebo využitý zčásti.
3. Plně nevyužité packy se rovnou smažou - levné, jeden požadavek na smazání každý.
4. Zčásti využité packy se přebalí: stáhnou se, jejich živé chunky se zapíší do nových packů, nové packy se nahrají a staré se smažou.
5. Index se přepíše, aby odpovídal.

Fáze 4 je místo, kde mizí čas a provoz, a právě ji ovládají volby:

--max-unused je ta důležitá. Přijímá procento, absolutní velikost jako 10G nebo unlimited. Při výchozích 5 % prune přebaluje zčásti využité packy, dokud zbývající odpad nespadne pod 5 % repozitáře. Při unlimited nepřebaluje nikdy: smaže plně nevyužité packy a skončí. Tím vyměníš trochu zbytečně zabraného místa - pack, kde se používá jediný chunk z padesáti, zůstane celý - za prune, který téměř nic nestahuje.

--max-repack-size práci naopak rozloží. Týdenní prune s --max-repack-size 2G nikdy v jednom běhu nepřesune víc než zhruba dva gigabajty, takže velký nedodělek po změně pravidla se vyřeší za několik týdnů, ne za jednu noc, která přetáhne do další zálohy.

--repack-uncompressed má smysl jen u repozitářů vytvořených před resticem 0.14 a povýšených na formát verze 2 pomocí restic migrate upgrade_repo_v2. Stará data zůstávají nekomprimovaná, dokud se nepřebalí, a tento přepínač to dělá postupně. Na novém repozitáři nedělá nic.

Před změnou těchto nastavení se vždy podívej na dry run s -v. Vypíše, kolik by se smazalo, kolik přebalilo a kolik nevyužitého místa by zbylo, což je přesně to číslo, se kterým obchoduješ.

Cena prune na S3#

Na lokálním disku je prune jen I/O. Na S3 je každý krok požadavek a u poskytovatelů, kteří je účtují, spadají náklady do čtyř druhů:

• Egress. Přebalování stahuje pack soubory. U poskytovatele, který účtuje odchozí provoz, je to největší náklad a právě ten řídí --max-unused.
• Požadavky. Výpis bucketu, čtení indexů, mazání packů. Za kus levné, ale repozitář o několika stovkách gigabajtů má desítky tisíc objektů.
• Upload. Nové packy z přebalování. Příchozí provoz bývá zdarma, ale na pomalé lince to trvá.
• Předčasné smazání. Třídy pro řídký přístup mají minimální dobu uložení - 30 dní u STANDARD_IA od Amazonu, 90 u Glacier Instant Retrieval - a dřívější smazání packu se účtuje, jako by zůstal.

To poslední je důvod, proč dvakrát zvážit -o s3.storage-class=STANDARD_IA. Packy v repozitáři resticu se při každém běhu prune neustále mažou, takže levnější třída úložiště může po započtení poplatků za předčasné smazání a vyzvednutí vyjít dráž. Archivní třídy, které před čtením objektu vyžadují požadavek na obnovu, jako Glacier Flexible Retrieval a Deep Archive, s repozitářem resticu nefungují vůbec, protože restic očekává, že může kdykoli přečíst libovolný pack.

Praktická nastavení podle situace:

Na úložišti, kde se provoz neúčtuje za gigabajt, je cena prune čas a exkluzivní zámek, ne peníze, a výchozí hodnota je v pořádku. Nastavení vyber jednou podle toho, jak účtuje tvůj poskytovatel, a zapiš ho do plánované úlohy, místo abys ho pokaždé vzpomínal.

Chyby zámků a zastaralé zámky#

restic používá soubory zámků, uložené jako objekty pod locks/ v repozitáři, aby se dva procesy nemohly navzájem poškodit. backup, restore a snapshots berou sdílený zámek; může jich běžet víc najednou. forget a prune berou exkluzivní zámek a potřebují repozitář jen pro sebe. Proces svůj zámek za běhu každých pár minut obnovuje.

Když exkluzivní operace narazí na jiný zámek nebo záloha narazí na běžící prune, zastaví se s něčím takovým (formulace se mezi verzemi trochu liší):

unable to create lock in backend: repository is already locked by PID 41234on web-01 by root (UID 0, GID 0)lock was created at 2026-10-12 04:30:02 (6h12m10s ago)storage ID 8c1d2e4fthe `unlock` command can be used to remove stale locks

Než cokoli uděláš, přečti si stáří a hostitele. Zámek starý pár minut patří procesu, který ještě pracuje: počkej. Zámek starý hodiny ze stejného hostitele, kde ps neukazuje žádný proces restic s daným PID, je zastaralý - zbyl po běhu, který byl zabit, po zastavení kvůli nedostatku paměti nebo po restartu.

• `restic unlock` odstraňuje jen zastaralé zámky: zámky, jejichž proces na tomto hostiteli už neexistuje, nebo které se víc než půl hodiny neobnovily. Je bezpečné ho spustit kdykoli.
• `restic unlock --remove-all` odstraní všechny zámky, včetně živých. Spusť to jen tehdy, když jsi si jistý, že repozitář nikde nepoužívá žádný proces restic; odstranit zámek běžícího prune a spustit zálohu je cesta, jak se repozitáře poškozují.
• `--retry-lock 30m` (restic 0.16 a novější) u jakéhokoli příkazu způsobí, že počká na zámek až tuto dobu, místo aby hned selhal. To je skutečné řešení pro plánované úlohy, které se občas překrývají.

Stáří zámku se posuzuje podle hodin zúčastněných strojů. Server s hodinami o hodinu pomýlenými může vidět čerstvý zámek jako zastaralý nebo zastaralý jako čerstvý, takže na všem, co zálohuje, nech běžet NTP.

Pokud si prune stěžuje na chybějící packy nebo nekonzistentní index, ne na zámek, zastav se a spusť restic check. restic repair index (před 0.16 nazvaný rebuild-index) přestaví index z packů, které skutečně existují, a bývá prvním krokem, než prune zase poběží.

Plánování pomocí systemd timerů#

Systemd timer je pro tuto práci lepší než cron: zmeškané běhy se po restartu dají dohnat, dva běhy téže jednotky se nikdy nepřekryjí, výstup jde do žurnálu s časovými razítky a selhání může spustit další jednotku. Potřebuješ stroj, kde systemd ovládáš - vlastní VPS nebo dedikovaný server - a obecný vzor je v článku systemd služby pro tvoje aplikace.

EnvironmentFile v systemd chce prosté řádky KEY=value, takže mu dej vlastní soubor, ne znovupoužitý shellový soubor plný řádků export:

AWS_ACCESS_KEY_ID=RNAKEXAMPLE123AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYAWS_DEFAULT_REGION=us-east-1RESTIC_REPOSITORY=s3:https://s3.example.com/my-bucket/restic/web-01RESTIC_PASSWORD_FILE=/etc/restic/web-01.passwordRESTIC_CACHE_DIR=/var/cache/restic

Služba zálohy spouští zálohu a levný forget:

[Unit]Description=restic backup and forgetWants=network-online.targetAfter=network-online.targetOnFailure=restic-alert@%n.service[Service]Type=oneshotEnvironmentFile=/etc/restic/web-01.envNice=10IOSchedulingClass=idleExecStart=/usr/bin/restic backup /srv /etc --host web-01 --tag files \    --one-file-system --retry-lock 30mExecStart=/usr/bin/restic forget --host web-01 --tag files \    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \    --keep-tag keep-forever --retry-lock 30m

[Unit]Description=Nightly restic backup[Timer]OnCalendar=*-*-* 04:30:00RandomizedDelaySec=15mPersistent=true[Install]WantedBy=timers.target

Služba oneshot může mít několik řádků ExecStart=; běží po řadě a služba selže u prvního, který selže, takže neúspěšná záloha přeskočí forget. Prune dostane vlastní službu a týdenní timer, aby pomalý prune nikdy nezdržel zálohu:

[Unit]Description=restic prune and checkOnFailure=restic-alert@%n.service[Service]Type=oneshotEnvironmentFile=/etc/restic/web-01.envNice=15IOSchedulingClass=idleExecStart=/usr/bin/restic prune --max-unused 10% --retry-lock 2hExecStart=/usr/bin/restic check --read-data-subset=5% --retry-lock 2h

Jeho timer je stejný jako u zálohy, jen s OnCalendar=Sun *-*-* 06:00:00. Pak:

$ systemctl daemon-reload$ systemctl enable --now restic-backup.timer restic-prune.timer$ systemctl list-timers 'restic-*'$ systemctl start restic-backup.service      # run once now, to test$ journalctl -u restic-backup.service -n 50

Persistent=true spustí zmeškanou úlohu jednou po startu, pokud byl stroj v plánovaný čas vypnutý. RandomizedDelaySec rozprostře několik serverů zálohujících do jednoho úložiště, aby nezačaly všechny ve stejné vteřině. OnFailure= spustí šablonovou jednotku, kterou si napíšeš sám - krátký skript, který pošle zprávu na webhook nebo e-mail - s názvem selhávající jednotky jako argumentem. Tahle část není volitelná: timer, který každou noc tiše selhává, vypadá úplně stejně jako timer, který funguje, a právě k tomu se neustále vrací článek monitoring, který ti něco řekne.

Pokud dáváš přednost cronu, stejné příkazy patří do obalového skriptu s --retry-lock a syntaxi plánu pokrývá článek výrazy cronu vysvětlené. Kolem skriptu přidej flock, aby se dva běhy nikdy nepřekryly, což ti systemd dává zadarmo.

Řešení potíží#

Repozitář je po forget stejně velký. Spustil jsi forget bez --prune a prune jsi nikdy nespustil. Nebo prune běžel s --max-unused unlimited a místo drží zčásti využité packy. Dry run s -v ukáže, kolik je nevyužito.

Staré snapshoty nikdy nevyprší. Zastaralá skupina - změněné cesty nebo změněné hostname. Hledej v forget --dry-run nadbytečný blok a vyčisti ho filtrem --host/--path, pak nastav --host u každé zálohy.

forget smazal snapshoty, které měl ponechat. Chyběl --keep-tag v tom běhu, --group-by slil dvě úlohy nebo hranice dne leží v jiném časovém pásmu. Sloupec s důvody v dry run vysvětluje každý ponechaný snapshot; co tam není, bylo smazáno záměrně.

Zálohy selhávají každou neděli ráno. Kolidují s exkluzivním zámkem prune. Přidej k záloze --retry-lock nebo přesuň prune na hodinu, kdy nic jiného neběží.

Prune běží hodiny a hodně stahuje. Velká změna pravidla nebo první prune po měsících. Omez ho pomocí --max-repack-size nebo zvyšuj --max-unused, dokud nedodělek nezmizí.

Adresář cache pořád roste. /var/cache/restic drží metadata každého repozitáře, který tento stroj otevřel. restic cache --cleanup odstraní cache repozitářů, které se nedávno nepoužily.

Ať zvolíš jakékoli pravidlo, obnov aspoň jednou něco z nejstaršího snapshotu, který ponechává. Je to jediný důkaz, že pravidlo ponechává to, co si myslíš, a článek vyzkoušej obnovu dřív, než ji budeš potřebovat ukazuje, jak z toho udělat rutinu.

FAQ#

Mám spouštět prune po každé záloze?

Ne. forget po každé záloze je levný a udržuje seznam snapshotů uklizený. prune stojí čas, provoz a exkluzivní zámek a místo, které uvolní mezi dvěma po sobě jdoucími nocemi, je nepatrné. Týdně stačí většině serverů; měsíčně je v pořádku na pomalé lince nebo když se účtuje egress.

Jaký je rozdíl mezi --keep-last a --keep-daily?

--keep-last 7 ponechá sedm nejnovějších snapshotů, kdykoli vznikly - při hodinových zálohách je to sedm hodin historie. --keep-daily 7 ponechá nejnovější snapshot z každého z posledních sedmi dnů, které nějaký mají, což je sedm dnů historie bez ohledu na četnost záloh.

Je bezpečné spustit forget, když běží záloha?

restic to nedovolí. Záloha drží sdílený zámek a forget potřebuje exkluzivní, takže forget buď selže s chybou zámku, nebo s --retry-lock počká, až záloha skončí. Totéž platí pro prune.

Mohou mít různé úlohy v jednom repozitáři různou retenci?

Ano. Označ každou úlohu tagem při zálohování a spusť jeden forget na tag s vlastním pravidlem, například --tag mysql --keep-daily 30 a --tag files --keep-daily 7. Filtr --tag způsobí, že každý běh sahá jen na své snapshoty.

Ušetří levnější třída úložiště S3 s resticem peníze?

Zřídka. Třídy pro řídký přístup účtují vyzvednutí a mazání objektů před minimálním stářím a prune packy neustále maže a přepisuje. Archivní třídy, které před čtením vyžadují obnovu, s resticem nefungují vůbec. Standardní úložiště je správná výchozí volba.

Jak ponechám jeden snapshot navždy?

Označ ho tagem - restic tag --add keep-forever <id> - a přidej --keep-tag keep-forever do každého příkazu forget. Tagování mění ID snapshotu, takže si ho potom znovu vyhledej pomocí restic snapshots.