Jak skonfigurować Rclone z Google Drive na serwerze bez monitora (Headless)

Rclone może kopiować pliki z serwera bez interfejsu graficznego na Google Drive. Autoryzacja odbywa się jednorazowo na komputerze z przeglądarką, a serwer korzysta później z zapisanej konfiguracji. Udane przesłanie pliku nie zastępuje jednak próby odtworzenia danych.

Poradnik obejmuje własnego klienta OAuth oraz przykład kopii plików przerywany w razie błędu. Potrzebne są konto Google z wolnym miejscem, dostęp przez SSH i Rclone na obu komputerach. Przykład obejmuje katalog witryny, a nie cały system operacyjny ani działającą bazę danych.

Faza 1: Własny klient Google

Aktualna dokumentacja Rclone zapowiada wycofanie wspólnego identyfikatora klienta Google Drive w 2026 roku. Własny identyfikator usuwa tę zależność. Nadal obowiązują limity Google i możliwe ograniczanie liczby żądań; osobny projekt nie znosi limitów API.

1. Utworzenie lub wybór projektu w Google Cloud Console oraz włączenie Google Drive API.
2. Uzupełnienie sekcji Branding i Odbiorcy w Google Auth Platform. Zwykłe prywatne konto Google korzysta z grupy odbiorców zewnętrznych.
3. Wskazanie potrzebnego zakresu dostępu. Przykład używa https://www.googleapis.com/auth/drive, czyli szerokiego dostępu do plików. Węższe zakresy obsługują inne zastosowania.
4. Utworzenie klienta OAuth typu Aplikacja na komputer (Desktop app). Identyfikator i sekret klienta będą potrzebne podczas konfiguracji Rclone.
5. Przy zewnętrznej aplikacji w stanie Testowanie token odświeżania z tym zakresem Drive wygasa po siedmiu dniach. Stała praca wymaga sprawdzenia właściwego stanu produkcyjnego i zasad weryfikacji. Publikacja usuwa ten konkretny limit testowy, ale nie wszystkie przyczyny wygaśnięcia tokenu.

Publikacja i weryfikacja przez Google to odrębne kroki. Przy użytku osobistym mogą obowiązywać wyjątki od weryfikacji. Osobnej oceny nadal wymagają ostrzeżenia, limity użytkowników i zasady organizacji.

Faza 2: Rozpoczęcie autoryzacji na serwerze

Na obu komputerach potrzebny jest Rclone. Wynik rclone version pozwala porównać wersje; dokumentacja konfiguracji zdalnej zaleca zgodne wersje. Debian i Ubuntu udostępniają pakiet przez sudo apt install rclone. Treść pytań może zależeć od wersji.

1. Na serwerze uruchomienie rclone config i utworzenie nowego połączenia o nazwie gdrive, typu drive.
2. Wprowadzenie własnego identyfikatora klienta, sekretu i wybranego zakresu. Ten wariant nie korzysta z konta usługi.
3. Odpowiedź n na pytanie o automatyczną autoryzację przez przeglądarkę. Rclone wyświetla właściwe polecenie rclone authorize dla lokalnego komputera i oczekuje na config_token.

Faza 3: Logowanie w lokalnej przeglądarce

Polecenie autoryzacji wyświetlone na serwerze uruchamia się na komputerze z przeglądarką. Po zalogowaniu do Google i udzieleniu zgody rclone authorize zwraca wynik do skopiowania. Wynik trafia do oczekującego dialogu serwera, po czym następuje zatwierdzenie konfiguracji. Zwykła lokalna sesja rclone config nie jest tym samym co ten etap wydania tokenu.

rclone lsd gdrive: sprawdza dostęp do folderów. Pusty dysk może zwrócić pustą listę; znaczenie mają również kod zakończenia i komunikaty błędów. rclone config file pokazuje położenie konfiguracji. Plik zawiera poświadczenia i musi pozostawać dostępny do odczytu oraz zapisu dla konta wykonującego kopię, bez udostępniania innym kontom.

Faza 4: Kopia plików i kontrola wyniku

Skrypt wymaga Bash, GNU tar, flock i Rclone. Przed użyciem konieczne jest dopasowanie katalogu źródłowego, katalogu kopii i nazwy połączenia. Archiwa muszą leżeć poza katalogiem źródłowym. To samo konto potrzebuje dostępu do plików i konfiguracji Rclone.

#!/bin/bash
set -euo pipefail
umask 077

SOURCE_DIR="/var/www/html"
BACKUP_DIR="$HOME/backups/www"
REMOTE="gdrive:ServerBackups"

mkdir -p -- "$BACKUP_DIR"
exec 9>"$BACKUP_DIR/.backup.lock"
flock -n 9 || { printf 'Backup already running\n' >&2; exit 1; }

NAME="www_$(date -u +%Y%m%dT%H%M%S%NZ).tar.gz"
ARCHIVE="$BACKUP_DIR/$NAME"
PART="$ARCHIVE.part"
trap 'rm -f -- "$PART"' EXIT

tar -czf "$PART" -C "$SOURCE_DIR" .
mv -- "$PART" "$ARCHIVE"
rclone copyto --immutable "$ARCHIVE" "$REMOTE/$NAME"
rclone check "$BACKUP_DIR" "$REMOTE" --include "/$NAME" --one-way

printf 'Archive uploaded and checked: %s\n' "$NAME"

Najpierw powstaje plik tymczasowy. Końcowa nazwa archiwum pojawia się dopiero po poprawnym zakończeniu tar. Przesłanie i porównanie przez rclone check również muszą zakończyć się powodzeniem, zanim pojawi się komunikat sukcesu. Blokada zapobiega równoczesnym uruchomieniom korzystającym z tego samego katalogu kopii. Porównanie sprawdza właściwości pliku lub dostępne sumy kontrolne, a nie działanie odtworzonej witryny.

Działająca witryna może zmieniać pliki podczas archiwizacji. Spójny stan wymaga odpowiedniej migawki lub uzgodnionego okna wykonywania kopii. Baza danych potrzebuje osobnego spójnego eksportu; archiwum /var/www/html nie obejmuje automatycznie działającej bazy.

Po ręcznej próbie cron może uruchamiać wykonywalny skrypt pod stałą ścieżką bezwzględną. Kody zakończenia i logi wymagają mechanizmu powiadamiania o błędach. Skrypt celowo nie usuwa starych archiwów: kopie lokalne i zdalne przyrastają do czasu wdrożenia reguły retencji. Reguła powinna uwzględniać minimalny zachowany zestaw, nieudane zadania, wolne miejsce i sprawdzone odtwarzanie.

Źródła i data weryfikacji

2026-10-24

• rclone.org — remote_setup
• rclone.org — drive
• developers.google.com — identity
• developers.google.com — identity
• rclone.org — commands
• rclone.org — crypt