Precis, här undviker du problemet genom att ta bort alla procenttecken. Vill du ha dem kvar för att formatera utskriften av `date` så måste du "escape:a" dina procenttecken med backslash, dvs i stället för att skriva:
* * * * * echo "Ja så har det ändå äntligen hänt, ska det va ska det va 100%"
så får du skriva
* * * * * echo "Ja så har det ändå äntligen hänt, ska det va ska det va 100\%"
i crontab.
Alternativet är att skapa ett externt skript som genomför backupen, och hålla crontab enkel. I detta fallet är det ju inte så komplexa åtgärder det handlar om, men i praktiken skulle du kunna
skapa det externa skriptet `/home/mc/bin/backup_minecraft` med innehåll:
#!/bin/sh
tar -cpzf /home/mc/backups/backup_$(date +%Y%m%d_%H%M%S).tar.gz /home/mc/mc/Minecraft
göra detta körbart (`chmod +x /home/mc/bin/backup_minecraft`)
kalla på detta genom crontab med en rad likt
0 0 * * * /home/mc/bin/backup_minecraft
Fördelen är att du är mindre begränsad i hur du utformar ditt skript. Här är det som sagt inte särdeles avancerat i vilket fall, men redan om man börjar använda subskal som du gör här så tycker jag det är smidigare att direkt lägga logik externt (det hade ju exempelvis undvikit problem för dig här). Att det går att använda generella skalkonstruktioner i crontab ser jag mer som en artefakt av dess konstruktion snarare än att det skulle vara ett fundamentalt designval att låta raderna vara Turingkompletta.
Att använda skript som kan köras på egen hand utanför cron gör det också enklare att felsöka, det är lätt att bygga in exempelvis en debugväxel, man kan lätt köra skriptet på godtycklig tid för att testa (i stället för att som du här ställa in cron på att köra raden varje minut för att kunna testa), du kan lättare återanvända logiken mellan flera olika crontabs, med mera. Kort sagt: se crontab mer som en enkel lista på saker att köra (som råkar ha lite extra "bells and whistles" tillgängliga) än en programmeringsmiljö.