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.

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

De huidige back-ups bevatten momenteel geen informatie over toegangsbeheer en geschiedenis.

The comments and suggestions are backed up with the username of the user who did create them. Upon import it is assigned to a matching user. If there is no user with such username, it is assigned to anonymous user.

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

Import validation of uploaded project backups can be tuned using 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, and PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

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. Zo krijgt u dat werkend:

  1. Koop de Back-updienst op https://weblate.org/support/#backup.

  2. Voer de verkregen sleutel in de beheerinterface in, 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

The directory where backups will be stored has to be owned by UID 1000, otherwise Weblate won’t be able to write the backups there.

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.

Zie ook

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:

Zie ook

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

Zie ook

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.

Zie ook

Achtergrondtaken met Celery

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.

Zie ook