Då bör rclone som koppla kontot till en mapp fungera - revisionshanteringen få du dock lösa på egen sätt om inte google-drive har något eget som jobbar i bakgrunden.
Ett alternativ om det 'bara' handlar om backup att kunna ta tillbaka när olyckan är framme är att titta på duplicay (prenumeration - dock rätt nice webbgränssnitt där du kan lägga tider etc.) och restic (cli-program och du får själv fixa schemaläggnningen med 'cron')
båda pratar mot molntjänster - är sessions-baserade (varav sessioner kan tas bort individuellt utan beroende av ordningsföljd eller beroenden av annan session) vilket gör att du får generationsbackupper, är deduplicerande backuper vilket gör att inte mer data än nödvändigt skickas upp till lagring och det gäller även förändringar inom stora databasfiler så är bara det som modifierats som skickas lagringen
Min personliga favorit är fortfarande borg-backup men pratar inte mot molntjänster - men använder man tex. 'rclone' som mappar en molntjänst till en mapp så är det inget som hindrar att lägga borg-backups repositorie där.
borgbackup är precis som restic och duplicacy deduplicerande backup-program med backupsessioner som kan raderas individuellt utan beroende och skickar inte upp mer data än nödvändigt mot lagringen samt alla arbetar med krypterade format och är krypterat innan datat lämnar datorn mot molnlagringen.
---
Slutligen - när du gör backup - är aktuella filer 'stängda' eller producerade som en backupfil av minecraft själva?. Att göra backup på filer som är under full användning samtidigt är ingen hit då databasen förmodligen hinner förändra sig invändigt många gånger medan backupprogrammet läser av filer och det som lagras är då korrupt och oanvändbart.
Detta är ett allmänt problem när det gäller backupper av filer och olika databaser som är aktiva och förändrar sig medans backup görs.
Skall man få ögonblicksbilder (ungefär som ett strömavbrott - vilket många databaser/filer kan göra recovery ifrån, men inte om modifieringarna har gjorts löpande medans backuppen tragglar igenom filen i långsam takt under tiden) så behöver man göra snapshot på atomisk nivå. Och det är för närvarade filsystem som BRFS och ZFS som kan erbjuda.
Eventuellt kan också snapshot göras på ext4 via LVM och då får en 'disk' en tid med frusen bild av monterade volymen som backup-program kan gå igenom utan att något hinner förändras under backupen, men så försvinner den efter en tag och kan inte sparas 'för evigt'. medans snapshot i BTRFS kan vara kvar så länge man önskar och kan tas bort oberoende av andra snapshot (aka subvolymer) gjorda före och efter medans ZFS är hierarkiskt och upptagna datat i snapshot är kvar tills hela datasetet skrotas eller gör rollback tillbaka till punkten innan gjorda snapshot