Weblate back-uppen en verplaatsen

Projectniveau back-ups

Added in version 4.14.

Het project back-upt alle inhoud van vertalingen van Weblate (project, onderdelen, vertalingen, opmerkingen bij tekenreeksen, suggesties of controles). Het is geschikt voor het verplaatsen van een project naar een andere instantie van Weblate.

De back-up bevat elk onderdeel in het project, inclusief beperkte onderdelen die de beheerder niet direct kan openen. Maken, vermelden en downloaden van deze back-ups vereist Projectinstellingen bewerken. Verleen dat recht alleen aan gebruikers die zijn te vertrouwen met de volledige inhoud van het project.

U kunt een back-up voor een project uitvoeren in Bewerkingen ↓ Back-ups. De back-up kan worden teruggezet bij het maken van een project (bekijk Vertaalprojecten en onderdelen toevoegen).

Notitie

Projectback-ups kunnen ook worden gemaakt, vermeld en gedownload met de Weblate REST API vanaf versie 2026.7;

The backups include project-scoped teams and their memberships, and project Opgeslagen zoekacties, but do not include history. Restored automatic team assignment rules invite matching new users to project teams and require acceptance before granting membership.

Bij het herstellen van back-ups met duplicate teamnamen worden alle teams behouden. Aanvullende teams met dezelfde naam krijgen een numeriek achtervoegsel, en de import rapporteert de hernoemde teams in zijn waarschuwingen. Ingebouwde teams worden afzonderlijk hersteld van aangepaste teams. Oudere back-ups leggen geen type team vast, dus duplicate items worden hersteld als bewerkbare aangepaste teams met numerieke achtervoegsels na het gemaakte ingebouwde team.

Ontbrekende mappen voor de opslagruimte worden overgeslagen, terwijl gegevens voor onderdelen en gegevens nog steeds worden geback-upt. Mislukkingen van onderhoud aan de opslagruimte worden gelogd en de back-up gaat door met de beschikbare bestanden in de opslagruimte. Toegang tot het bestandssysteem en I/O-fouten zorgen ervoor dat de back-up mislukt en onvolledige archieven worden verwijderd. Herstellen van een back-up met ontbrekende of ongeldige metadata voor de opslagruimte behoudt de beschikbare bestanden, onderdelen en vertaalgegevens, maar de opslagruimte moet afzonderlijk worden hersteld.

De opmerkingen en suggesties worden geback-upt met de gebruikersnaam van de gebruiker die ze maakte. Bij het importeren wordt het toegewezen aan een overeenkomende gebruiker. Als er geen gebruiker is met die gebruikersnaam, wordt het toegewezen aan een anonieme gebruiker.

De gegenereerde back-ups worden behouden op de server zoals is geconfigureerd in PROJECT_BACKUP_KEEP_DAYS en PROJECT_BACKUP_KEEP_COUNT (het heeft een standaard van ten hoogste 3 back-ups voor 30 dagen).

Importeren van validatie van geüploade projectback-ups kan fijn worden afgestemd met PROJECT_BACKUP_IMPORT_MAX_MEMBERS, PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE, PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE, PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE en PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

De volledige back-up wordt gevalideerd voordat enige gegevens worden teruggezet. Ongeldige objectvelden, verwijzingen, paden voor opslagruimten, URL’s, reguliere expressies of bestanden van schermafdrukken zorgen ervoor dat het importeren wordt geweigerd, zonder een gedeeltelijk project te maken.

Extensies van schermafdrukbestanden worden gecorrigeerd om overeen te komen met hun gevalideerde afbeeldingsinhoud tijdens het importeren. Dit repareert ook oudere back-ups die bestandsnamen bevatten zoals: schermafdruk.pngrawtrue. Ongeldige afbeeldingen worden nog steeds afgekeurd.

Upgraden naar Weblate 2026.11 past dezelfde reparatie toe op opgeslagen schermafdrukken. Ontbrekende of ongeldige afbeeldingen worden niet veranderd en worden gerapporteerd in het migratielogbestand. Oorspronkelijke bestanden worden behouden tot een gepland opschonen van schermafdrukken ze verwijdert.

Versiecontrole en bestandsformaatparameters worden vanuit oudere back-upformaten gemigreerd voordat hun waardes worden gevalideerd. Onbekende parameters en parameters die niet van toepassing zijn op het versiecontrole- of bestandsformaatsysteem van het huidige onderdeel worden overgeslagen en gerapporteerd in importwaarschuwingen. Ongeldige waardes voor ondersteunde parameters zorgen ervoor dat de import geweigerd wordt. Waarden moeten de types gebruiken die opgeslagen zijn door Weblate, booleaanse parameters vereisen bijvoorbeeld JSON booleanse waarden en geen tekenreeksen.

Gebruik het gegenereerde bestand om het project te importeren bij Vertaalprojecten en onderdelen toevoegen of in import_projectbackup.

Notitie

Terugzetten van de back-up zou kunnen mislukken als de server voor het terugzetten een andere set Taaldefinities of andere configuratie van SIMPLIFY_LANGUAGES heeft. Het terugzetten zal u zeggen welke taalcodes niet werden verwerkt en u kunt dan handmatig ontbrekende taaldefinities toevoegen.

Geautomatiseerde back-up met BorgBackup

Weblate heeft ingebouwde ondersteuning voor het maken van service back-ups met BorgBackup. Borg maakt ruimtebesparende versleutelde back-ups die veilig kunnen worden opgeslagen in de cloud. De back-ups kunnen worden beheerd in de beheerinterface op de tab Back-ups.

Veranderd in versie 4.4.1: PostgreSQL databases zijn opgenomen in de geautomatiseerde back-ups.

De back-ups die Borg gebruikt zijn verhogend en Weblate is geconfigureerd om de volgende back-ups te behouden:

  • Dagelijkse back-ups tot 14 dagen geleden

  • Wekelijkse back-ups tot 8 weken terug

  • Maandelijkse back-ups tot 6 maanden terug

../_images/backups.webp

Borg sleutel voor versleuteling

BorgBackup maakt versleutelde back-ups en u zult ze niet kunnen terugzetten zonder de beveiligingsfrase. De beveiligingsfrase wordt gegenereerd bij het toevoegen van een nieuwe service voor back-up en u zou hem moeten kopiëren en moeten bewaren op een veilige plek.

Als u Door Weblate verschafte opslag voor back-up gebruikt, back-up ook uw privé SSH-sleutel, omdat die wordt gebruikt voor toegang tot uw back-ups.

Zie ook

borg init

Back-up aanpassen

Door Weblate verschafte opslag voor back-up

De gemakkelijkste manier voor het back-uppen van uw instantie van Weblate is door het aankopen van de back-up service op weblate.org. Het is beschikbaar voor Weblate dat wordt uitgevoerd in uw eigen omgeving en geen hosting of afzonderlijk abonnement voor ondersteuning vereist.

Zo krijgt u het werkend:

  1. Open, in de beheersinterface, Back-ups en selecteer Back-upservice kopen, of koop de back-upservice direct.

  2. Voer de verkregen activatiesleutel in bij Ondersteuningspakket activeren op de pagina Back-ups, bekijk Ondersteuning integreren.

  3. Weblate verbindt met de cloudservice en verkrijgt toegangsinformatie voor de back-ups.

  4. Schakel de nieuwe configuratie voor de back-up in op de tab Back-ups.

  5. Back-up uw inloggegevens voor Borg om de back-ups terug te kunnen zetten, bekijk Borg sleutel voor versleuteling.

Hint

De handmatige stap om alles in te schakelen is er voor uw veiligheid. Zonder uw instemming worden geen gegevens verzonden naar de opslagruimte voor de back-up die is verkregen bij het registratieproces.

Aangepaste opslag back-up gebruiken

U kunt ook uw eigen opslag gebruiken voor de back-ups. SSH kan worden gebruikt om back-ups op te slaan op de bestemming op afstand, op de doelserver moet BorgBackup zijn geïnstalleerd.

Zie ook

General in de documentatie van Borg

Lokaal bestandssysteem

Aanbevolen wordt om het absolute pad te specificeren voor de lokale back-up, bijvoorbeeld /pad/naar/back-up. In de map moet kunnen worden geschreven door de gebruiker die Weblate uitvoert (bekijk Rechten voor bestandssysteem). Als die niet bestaat, zal Weblate proberen hem te maken, maar het heeft de toepasselijke rechten nodig om dat te kunnen doen.

Hint

Bij het uitvoeren van Weblate in Docker, zorg er dan voor dat de locatie voor de back-up wordt weergegeven als een volume uit de container van Weblate. Anders zullen de back-ups worden genegeerd door Docker, tot de container waarin het staat opnieuw wordt gestart.

Een optie is om back-ups te plaatsen in een bestaand volume, bijvoorbeeld /app/data/borgbackup. Dit is een bestaand volume in de container.

U kunt ook een nieuwe container toevoegen voor de back-ups in het Docker Compose-bestand, bijvoorbeeld door te gebruiken /borgbackup:

services:
  weblate:
    volumes:
      - /home/weblate/data:/app/data
      - /home/weblate/borgbackup:/borgbackup

De map waarin de back-ups zullen worden opgeslagen moet als eigenaar UID 1000 hebben, anders zal Weblate niet in staat zijn de back-ups daar weg te schrijven.

Back-ups op afstand

Voor het maken van back-ups op afstand zult u BorgBackup moeten installeren op een andere server, die toegankelijk is voor uw uitgerolde Weblate via SSH met de sleutel van Weblate voor SSH:

  1. Een server voorbereiden waar uw back-ups zullen worden opgeslagen.

  2. Installeer de SSH-server erop (u zult dit standaard krijgen bij de meeste distributies van Linux).

  3. Installeer BorgBackup op die server; de meeste distributies van Linux hebben pakketten beschikbaar (bekijk Installation).

  4. Kies een bestaande gebruiker of maak een nieuwe gebruiker die voor de back-ups zal worden gebruikt.

  5. Voeg de sleutel voor Weblate van SSH toe aan het bestand .ssh/authorized_keys van de gebruiker, zodat Weblate SSH naar de server kan zonder een wachtwoord (bekijk Weblate SSH-sleutel).

  6. Maak een door de gebruiker te beschrijven map waar Weblate op afstand de opslagruimte voor Borg back-up kan instellen, bijvoorbeeld in de persoonlijke map (d.i. /home/borg/backups).

  7. Configureer de locatie voor de back-up in Weblate als user@host:/home/borg/backups of ssh://user@host:port/home/borg/backups.

  8. Eenmaal ingeschakeld zullen de back-ups dagelijks automatisch worden geactiveerd. U kunt ook handmatig een back-up activeren vanuit de gebruikersinterface van Weblate of backup gebruiken.

Hint

Door Weblate verschafte opslag voor back-up verschaft u zonder enige moeite geautomatiseerde back-ups op afstand.

Terugzetten vanaf BorgBackup

  1. Herstel toegang tot de opslagruimte van uw back-up en bereid uw wachtwoord voor uw back-up voor.

  2. Vermeld alle back-ups op de server met borg list REPOSITORY.

  3. Zet de gewenste back-up terug in de huidige map met borg extract REPOSITORY::ARCHIVE.

  4. Zet de database terug vanuit de SQL dump die is geplaatst in de map backup in de map met gegevens van Weblate (bekijk Gedumpte gegevens voor back-ups).

  5. Kopieer de configuratie van Weblate (backups/settings.py, bekijk Gedumpte gegevens voor back-ups) naar de juiste locatie, bekijk Configuratie aanpassen.

    Bij het gebruiken van Docker container, is het bestand met instellingen al opgenomen in de container en zou u de originele omgevingsvariabelen moeten terugzetten. Het bestand environment.yml zou u daarmee kunnen helpen (bekijk Gedumpte gegevens voor back-ups).

  6. Kopieer de gehele map met teruggezette gegevens naar de locatie die wordt geconfigureerd door DATA_DIR.

    Plaats, bij het gebruiken van Docker container, de gegevens in het volume data, bekijk Docker container volumes.

    Zorg ervoor dat de bestanden de juiste eigenaar en rechten hebben, bekijk Rechten voor bestandssysteem.

De sessie van Borg zou er zo uit kunnen zien:

$ borg list /tmp/xxx
Enter passphrase for key /tmp/xxx:
2019-09-26T14:56:08 Thu, 2019-09-26 14:56:08 [de0e0f13643635d5090e9896bdaceb92a023050749ad3f3350e788f1a65576a5]
$ borg extract /tmp/xxx::2019-09-26T14:56:08
Enter passphrase for key /tmp/xxx:

Herstellen van op Docker gebaseerde opstelling

De volgende stappen gaan uit van de officiële Docker Compose-instellingen met de gebundelde services voor PostgreSQL en Valkey, bekijk Installeren met Docker. Als uw uitrol een externe database of een aangepast bestand Compose gebruikt, pas dan de stappen voor de database en het volume aan voor die omgeving.

Begin met een checkout van Docker Compose die overeenkomt met de herstelde uitrol. herstel uw originele overschrijvingen van Compose, geheime wachtwoorden en omgevingsvariabelen. Het bestand environment.yml van Gedumpte gegevens voor back-ups kan daarbij helpen, maar het wordt niet automatisch geïmporteerd.

  1. Herstel het back-uparchief met Terugzetten vanaf BorgBackup of pak uw back-up handmatig uit, zodat de Weblate gegevensmap en backups/database.sql beschikbaar komen.

  2. Stop de services die naar de database of het gegevensvolume kunnen schrijven:

    docker compose stop weblate cache
    
  3. Maak het volume van PostgreSQL opnieuw.

    docker compose stop database
    docker compose rm -v database
    docker volume remove weblate-docker_postgres-data
    

    De naam voor het volume is afhankelijk van de projectnaam van Compose en mag anders zijn dan die in weblate-docker_postgres-data. Controleer uw instellingen voordat u een volume verwijdert.

  4. Start de databaseservice:

    docker compose up -d database
    
  5. Zet de databasedump terug:

    cat backups/database.sql | docker compose exec -T database psql --username weblate --dbname weblate
    

    Controleer of de naam van de database overeenkomt met POSTGRES_DB en dat de gebruiker overeenkomt met POSTGRES_USER in uw configuratie voor Compose.

  6. Herstel de Weblate gegevensmap naar het Docker gegevensvolume dat is gemount als /app/data, bekijk Docker container volumes. Bestanden in dat volume moeten eigendom zijn van UID 1000, bekijk Rechten voor bestandssysteem.

  7. Start de resterende services en volg de logs:

    docker compose up -d
    docker compose logs -f
    

    De Weblate container voert migraties van de database uit bij opstarten. Als u Weblate ook upgradet, volg Upgraden van de Docker container.

  8. Vernieuw de opslagruimten na het herstellen:

    docker compose exec --user weblate weblate weblate updategit --all
    

Handmatige back-up

Afhankelijk van wat u wilt opslaan, back-up het type gegevens dat Weblate op elke respectievelijke plaats opslaat.

Hint

Als u de handmatige back-ups uitvoert, zou u misschien de waarschuwing van Weblate over een gebrek aan back-ups willen uitschakelen door weblate.I028 toe te voegen aan SILENCED_SYSTEM_CHECKS in settings.py of WEBLATE_SILENCED_SYSTEM_CHECKS voor Docker.

SILENCED_SYSTEM_CHECKS.append("weblate.I028")

Database

De feitelijke locatie van het opslaan is afhankelijk van de instellingen van uw database.

Hint

De database is de meest belangrijke opslag. Stel regelmatige back-ups voor uw database in. Zonder de database zijn alle vertalingen verloren.

Eigen database back-up

De aanbevolen werkwijze is om een dump van de database op te slaan met eigen gereedschappen van de database, zoals pg_dump. Het presteert gewoonlijk beter dan de back-up van Django, en het zet volledige tabellen met al hun gegevens terug.

U kunt deze back-up terugzetten in een nieuwere uitgave van Weblate, het zal alle benodigde migraties uitvoeren als het wordt uitgevoerd in migrate. Raadpleeg Weblate upgraden voor meer gedetailleerde informatie over hoe te upgraden tussen versies.

Django database back-up

Als alternatief kunt u uw database back-uppen met Django’s opdracht dumpdata. Op die manier wordt de back-up database agnostisch en kan worden gebruikt in het geval u de backend van de database wilt wijzigen.

Voorafgaande aan het terugzetten van de database moet u exact dezelfde versie van Weblate uitvoeren als waarop de back-up werd gemaakt. Dit is noodzakelijk omdat de databasestructuur wijzigt tussen uitgaven en u zou kunnen eindigen met op een of andere manier corrupte gegevens. Na het installeren van dezelfde versie, voer alle migraties voor de database uit met migrate.

Daarna zullen sommige items al zijn gemaakt in de database en zult u ze ook in de back-up van de database hebben. De aanbevolen werkwijze is om dergelijke items handmatig te verwijderen met de shell voor beheer (bekijk Opdrachten voor beheer uitvoeren):

weblate shell
>>> from weblate.auth.models import User
>>> User.objects.get(username='anonymous').delete()

Bestanden

Wanneer u voldoende ruimte hebt voor back-ups, back-up eenvoudigweg de gehele DATA_DIR. Dit is een veilige keuze, zelfs als het wat bestanden bevat die u niet nodig hebt. De volgende gedeelten beschrijven in detail wat u zou moeten back-uppen en wat u kunt overslaan.

Gedumpte gegevens voor back-ups

Veranderd in versie 4.7: De omgevingsdump werd toegevoegd als environment.yml om te helpen bij het terugzetten in de omgevingen van Docker.

Opgeslagen in DATA_DIR /backups.

Weblate dumpt hier verscheiden gegeven en u kunt deze bestanden opnemen voor meer complete back-ups. De bestanden worden dagelijks bijgewerkt (vereist een uitgevoerde Celery beats server, bekijk Achtergrondtaken met Celery). Momenteel omvat dit:

  • Weblate instellingen als settings.py (er is ook een uitgebreide versie in settings-expanded.py).

  • PostgreSQL database back-up als database.sql.

  • Omgevingsdump als environment.yml.

De back-ups van de database worden standaard als platte tekst opgeslagen, maar zij kunnen ook worden gecomprimeerd of volledig worden overgeslagen met DATABASE_BACKUP.

Laad, om de back-up van de database terug te zetten, hem met de gereedschappen voor de database, bijvoorbeeld:

psql --file=database.sql weblate

Opslagruimten versiebeheer

Opgeslagen in DATA_DIR /vcs.

De opslagruimten voor versiebeheer bevatten een kopie van de opslagruimten upstream met wijzigingen van Weblate. Als u Pushen na commit hebt ingeschakeld voor al uw onderdelen voor vertalingen, worden alle wijzigingen in Weblate in upstream opgenomen. Geen noodzaak om de opslagruimten ook aan de kant van Weblate te back-uppen, omdat zij opnieuw kunnen worden gekloond vanaf de locatie van upstream, zonder gegevensverlies.

Sleutels voor SSH en GPG

Opgeslagen in DATA_DIR /ssh en DATA_DIR /home.

Als u sleutels voor SSH of GPG gebruikt die zijn gegenereerd door Weblate zou u deze locaties moeten back-uppen. Anders zult u de privésleutels verliezen en zult u nieuwe moeten genereren.

Gemaakte SSH-wrapperscripts worden opgeslagen in CACHE_DIR en hoven niet te worden geback-upt.

Door gebruiker geüploade bestanden

Opgeslagen in DATA_DIR /media.

U zou alle door gebruikers geüploade bestanden moeten back-uppen (bijv. Schermafdrukken en visuele context).

Taken van Celery

De wachtrij van taken van Celery zou enige informatie kunnen bevatten, maar is gewoonlijk niet nodig voor een back-up. U zult ten hoogste bijwerkingen verliezen die nog niet zijn verwerkt in het vertaalgeheugen. Aanbevolen wordt toch al om het bijwerken van de volledige tekst of de opslagruimten uit te voeren bij terugzetten, er bestaat dus geen probleem om ze te verliezen.

Opdrachtregel voor handmatige back-up

Met een cron job kunt u een opdracht voor Bash instellen om op dagelijkse basis te worden uitgevoerd, bijvoorbeeld:

$ tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups vcs ssh home media fonts secret

U kunt de lijst met mappen en bestanden naar uw behoeften aanpassen. Voor het niet opslaan van het vertaalgeheugen (in de map backups), kunt u gebruiken:

$ tar -Jcf ~/backup/weblate-backup-$(date -u +%Y-%m-%d_%H%M%S).xz backups/database.sql backups/settings.py vcs ssh home media fonts secret

Terugzetten van handmatige back-up

  1. Alle gegevens terugzetten die u heeft geback-upt.

  2. Werk alle opslagruimten bij met updategit.

    weblate updategit --all
    

Een installatie van Weblate verplaatsen

Verplaats uw installatie naar een ander systeem door de instructies voor back-uppen en terugzetten hierboven te volgen.