Voer het opschonen van de bewaartermijn uit na een geslaagde back-up, maar plan het comprimeren van de repository minder vaak en buiten het belangrijkste back-upvenster. Borg 1.4 scheidt het verwijderen van archieven van het daadwerkelijk vrijgeven van schijfruimte. Daarom hoef je niet na elke borg prune borg compact uit te voeren.
Deze handleiding is gericht op het huidige stabiele opdrachtmodel van Borg 1.4.x. Borg 2 wijzigt de semantiek van repositories en archieven op verschillende punten. Controleer daarom de geïnstalleerde versie voordat je automatisering uit een andere hoofdversie overneemt.
Bevestig de Borg-versie en repository
borg --version
borg info /mnt/backup/borg-repo
borg list /mnt/backup/borg-repo
De Borg-FAQ vermeldt dat Borg een repositorybrede vergrendeling gebruikt en dat slechts één proces tegelijk schrijftoegang kan hebben. Als een lange compact-bewerking overlapt met de volgende geplande back-up, wacht de back-up op de vergrendeling of mislukt deze wanneer de time-out voor de vergrendeling verstrijkt.
Definieer de bewaartermijn eerst met een proefrun
borg prune is destructief voor de archiefgeschiedenis. De prune-documentatie van Borg raadt sterk aan om te testen met --dry-run en --list.
borg prune --dry-run --list --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' /mnt/backup/borg-repo
Als één repository back-ups van meerdere machines of datasets bevat, is het archieffilter essentieel. Zonder een beperkend filter beschouwt Borg 1.4 alle archieven in de repository als kandidaten voor dezelfde bewaarbeleidsregels.
Voer prune alleen uit na een geslaagde back-up
#!/bin/sh
set -eu
REPO=/mnt/backup/borg-repo
ARCHIVE='{hostname}-{now:%Y-%m-%d_%H-%M}'
borg create --stats "$REPO::$ARCHIVE" /srv/data
borg prune --list --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' "$REPO"
Voer prune niet uit omdat een planner is geactiveerd; voer prune uit omdat een nieuwe back-up succesvol is voltooid en het bewaarbeleid al is gevalideerd.
Begrijp waarom prune niet onmiddellijk ruimte vrijmaakt
Sinds Borg 1.2 staat compact los van normale opdrachten die naar de repository schrijven. In de afzonderlijke opmerkingen over compact van Borg wordt uitgelegd dat het verwijderen of opschonen van archieven niet onmiddellijk alle schijfruimte van de repository terugwint.
borg create
|
nieuw archief vastgelegd
|
borg prune
|
oude archieven uit de bewaarlijst verwijderd
|
borg compact
|
ruimte in ongebruikte segmenten teruggewonnen
Dit is nuttig voor de planning, omdat dagelijkse back-ups niet de volledige kosten hoeven te dragen van het herschrijven van gedeeltelijk gebruikte repositorysegmenten.
Plan compact minder vaak dan prune
- back-up: elke nacht;
- prune: na elke geslaagde back-up of enkele keren per week;
- compact: eenmaal per week tijdens een rustige periode;
- volledige repositorycontrole: volgens een afzonderlijk, minder frequent schema.
# Dagelijkse back-up + prune
0 1 * * * /usr/local/sbin/borg-backup
# Wekelijks compact
0 4 * * 0 /usr/local/sbin/borg-compact
Als back-ups vaak meerdere uren duren, plan het compacteren verder weg of gebruik een timer met expliciete afhankelijkheden.
Gebruik de standaarddrempel voor compact voordat je maximale herschrijvingen afdwingt
De huidige documentatie over compact gebruikt standaard een drempel van 10%.
borg compact --progress /mnt/backup/borg-repo
Deze standaardwaarde is een goed uitgangspunt wanneer een kort onderhoudsvenster prioriteit heeft. Gebruik niet automatisch --threshold 0; bij elke mogelijkheid om ruimte te besparen wordt het archief opnieuw geschreven, wat op een grote repository aanzienlijk trager kan zijn.
Voorkom dat onderhoud samenvalt met de volgende back-up
Als een taak rechtmatig op een ander Borg-proces moet wachten, stel dan een begrensde wachttijd voor de vergrendeling in:
borg --lock-wait 1800 create /mnt/backup/borg-repo::'{hostname}-{now}' /srv/data
Gebruik geen extreem lange wachttijd op de vergrendeling als vervanging voor een goede planning. Houd bij wanneer de back-up daadwerkelijk begint en eindigt.
Als meerdere clients één repository delen, spreid hun schema's dan. De FAQ van Borg vermeldt dat meerdere repositories lock-contentie kunnen verminderen wanneer deduplicatie tussen clients niet belangrijk is.
Gebruik Quick Stats wanneer rapportage prune vertraagt
Borg 1.4.5 voegde dit toe --quick-stats om aan te maken, te verwijderen en te prunen, waarbij tragere statistieken voor de hele repository worden vermeden wanneer die niet nodig zijn.
borg prune --quick-stats --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --glob-archives '{hostname}-*' /mnt/backup/borg-repo
Houd vrije ruimte beschikbaar voordat je compact nodig hebt
Wacht niet tot het bestandssysteem van de repository geen vrije ruimte meer heeft. Borg kan normale schrijfbewerkingen naar de repository niet betrouwbaar uitvoeren op een volledig vol bestandssysteem.
df -h /mnt/backup
borg info /mnt/backup/borg-repo
Voor een uitgebreider NAS-back-upplan is de 3-2-1-back-upgids van ZimaOS een nuttige herinnering dat de retentie van een repository slechts één laag van back-upontwerp is.
Valideer het schema voordat je erop vertrouwt
- Heeft elke back-up een nieuw archief aangemaakt?
- Werd prune alleen uitgevoerd na geslaagde back-ups?
- Kwam de retentieset overeen met het dry-run-plan?
- Was de wekelijkse compact voltooid vóór de volgende back-up?
- Nam de vrije ruimte toe na compact?
- Heeft een taak onverwacht lang gewacht op de Borg-vergrendeling?
Als compact herhaaldelijk samenvalt met de volgende back-up, verlaag dan de frequentie van compact, behoud de standaarddrempel, verplaats compact naar een rustiger tijdstip of splits niet-gerelateerde workloads op in afzonderlijke repositories.
Een Borg-onderhoudspatroon met minimale onderbreking
DAGELIJKS
01:00 borg create
|
+-- geslaagd --> borg prune
|
+-- fout --> oude archieven behouden, waarschuwing geven
WEKELIJKS
04:00 borg compact
PERIODIEK
borg check
geselecteerde bestanden herstellen
De hoofdregel is eenvoudig: prune beschermt het retentiebeleid; compact maakt opslagruimte vrij; ze hoeven niet met dezelfde frequentie te worden uitgevoerd.
Ondersteuning & Tips
Meer om te lezen

Home Assistant werkt via wifi, maar niet via ethernet of VPN
Test elk netwerkpad afzonderlijk, controleer de interface- en routeringsstatus, maak onderscheid tussen rechtstreeks IP-verkeer en ontdekking, en herstel vervolgens alleen de defecte laag.

Hoe je Home Assistant buiten gebruik stelt zonder onbeveiligde gegevens achter te laten
Bewijs de vervanging of archivering, trek elk vertrouwenspad in, wis elk gegevensdragend apparaat veilig en bewaar uitsluitend gedocumenteerde beschermde herstelkopieën.

Moet je automatische updates voor Home Assistant op een homeserver gebruiken?
Kies handmatige updates, updates met alleen meldingen of gefaseerde automatische updates op basis van de impact op het huishouden, het compatibiliteitsrisico, de observatietijd en...

