ubuntuusers.de

Ok, aber warum tut es nichts?

Navaria schrieb:

Ok, aber warum tut es nichts?

Offensichtlich werden keine alten Backups abgeräumt: zwischen Zeile 9 und 10 der Ausgabe steht nix. Wenn etwas gelöscht würde, würde ja mindestens die Ausgabe aus Zeile 21 auftauchen.

Es hat sich übrigens die Konvention als nützlich erwiesen, Variablen, die nur innerhalb des Skriptes benutzt werden, klein zu schreiben. Die Umgebungsvariablen wie $HOME und $PATH werden alle groß geschrieben.

Ja logisch.... wenn man die Testdaten auch mit einem normalen cp kopiert wird der Timestamp natürlich angefasst... ergo: Nichts zum löschen da 😀

Hab die Testdaten noch mal mit cp -p bereitgestellt und siehe da:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Backup Dir: /home/markus/foundry/backup/vtt1/testdata
DelFile: /home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-15_040001.tar.gz
UsrDat Dir: /home/markus/foundry/server/vtt1/foundrydata
Log Dir: /home/markus/foundry/logs/vtt1/backuplogs
Logfile: /home/markus/foundry/logs/vtt1/backuplogs/backupData_2023-09-18_152346.log
Alte Backups werden entfernt...
'/home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-15_040001.tar.gz' wurde entfernt
'/home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-22_040001.tar.gz' wurde entfernt
'/home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz' wurde entfernt
'/home/markus/foundry/backup/vtt1/testdata/backupData_2023-09-05_040001.tar.gz' wurde entfernt
Delete file /home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-15_040001.tar.gz
Delete file /home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-22_040001.tar.gz
Delete file /home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz
Delete file /home/markus/foundry/backup/vtt1/testdata/backupData_2023-09-05_040001.tar.gz
Alte Backup-Logs werden entfernt...

Ok, ich denke so komme ich weiter was das Löschen angeht.

Dann muss ich noch den Upload einbauen.

1
2
3

for f in "$backup_dir"/*; do
  [ $(date +%s -r "$f") -ge $ts ] && echo dropbox_upload upload
done

Muss das nicht dropbox_upload upload $f heißen?

Navaria schrieb:

Ja logisch.... wenn man die Testdaten auch mit einem normalen cp kopiert wird der Timestamp natürlich angefasst... ergo: Nichts zum löschen da 😀

😛

1 2 3

for f in "$backup_dir"/*; do [ $(date +%s -r "$f") -ge $ts ] && echo dropbox_upload upload done

Muss das nicht dropbox_upload upload $f heißen?

Das ist ja nur ein echo - da kannst Du verwenden, was Du willst. 😉 Aber in der endgültigen Lösung sollte da am Ende "$f" stehen, ja.

Mal so als Input und Food for Thought habe ich mal eine Variante gebaut (ungetestet) mit folgenden Änderungen:

• Debugging über Umgebungsvariable eingeschaltet.

• Skript-Variablen klein geschrieben

• Variablen so definiert, dass sie doppelte Angaben vermeiden (vergleiche Zeilen 6 und 7 Deines Skriptes und auch die unnötige Redundanz von "$HOME/foundry/backup/vtt1"). Der Witz von Variablen ist ja, dass man sie ein Mal definieren und dann mehrfach verwenden kann, so dass man sicher ist, dass immer der gleiche Wert benutzt wird.

• Die Logdatei wird exact ein Mal geöffnet, was schneller geht und sicherstellt, dass alle Ausgaben in einer Datei landen. (Es gibt die Möglichkeit, dass jemand die Logdatei woanders hin schiebt, während Dein Skript läuft. Der Trick mit dem offenen Dateideskriptor sorgt dafür, dass trotzdem alle Ausgaben, die zusammen gehören, in derselben Datei landen. Das wiederholte Öffnen würde dann dazu führen, dass ein Teil in der verschobenen Datei landet und ein Teil in einer neuen Datei an der.)

• Here-Doc für Ausgabe eines ganzen Blockes (Zeilen 19ff).

• Das Löschen mit find vereinfacht mit "-delete".

Man könnte auch gleich Stdout in die Logdatei umleiten. Dann braucht man die ganzen ">&9" nicht mehr.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

#!/bin/bash

# enable debugging via environment variable DEBUG
[ -z "$DEBUG" ] || set -x

date=$(date '+%Y-%m-%d_%H%M%S')
base="$HOME/foundry/backup/vtt1"
backup_dir="$base/testdata"                    # Variable gab es bereits. rklm: Funktioniert das hier auch in deinem Vorschlag?
backup="$backup_dir/backupData_$date.tar.gz"
delfile=("$backup_dir"/*)                                          # neue Variable gem. Vorschlag rklm
data_dir="$base/foundrydata"
log_dir="$base/backuplogs"
logfile="$log_dir/backupData_$date.log"

# open log
exec 9>>"$logfile"

# Variablen ausgeben, fuer Debug Zwecke
cat <<LOG_HEADER >&9
Backup Dir: $backup_dir
DelFile: $delfile
UsrDat Dir: $data_dir
Log Dir: $log_dir
Logfile: $logfile
LOG_HEADER

# Backup erstellen
tar -czvf "$backup" "$data_dir" "$(realpath --relative-to ../dummy "$data_dir")" >&9
dropbox_uploader upload "$backup"

# Alte Backups entfernen
echo Alte Backups werden entfernt... >&9
find "$backup_dir"/*.tar.gz -type f -mtime +14 -delete -print >&9

# Vorschlag rklm fuer das Loeschen in der Dropbox
# Hier erst mal nur Ausgabe, was das Script loeschen wuerde
for f in "${delfile[@]}"; do
  [ -e "$f" ] || dropbox_uploader delete "$f" >&9
done

# Alte Backup-Logs entfernen
echo Alte Backup-Logs werden entfernt... >&9
find "$log_dir" -name 'backupData*.log' -type f -mtime +14 -delete -print >&9

echo Fettich >&9

Viel Spaß! ☺

Wow rklm, vielen Dank fürs Optimieren. Zwei offensichtliche Fehler habe ich schon gefunden:

1
2
3

# Wird nicht funktionieren
# data_dir="$base/foundrydata"
# log_dir="$base/backuplogs"

Da liegen andere Pfade drunter, aber das weiß ich zu beheben ☺

Zwei Dinge sind mir noch nicht klar:

1.) Ich seh den Sinn von

1
2

# Enable debugging via environment variable DEBUG
[ -z "$DEBUG" ] || set -x

nicht, weil du die Variable $DEBUG nie abfragst, überhaupt verstehe ich die Zeile nicht. Erläuterung? ☺

2.) Die Variable $delfile ist ja offensichtlich ein Array aus Dateinamen /-pfaden.

1
2

cat <<LOG_HEADER >&9
DelFile: $delfile

würde aber ja nur den ersten Dateinamen /-pfad ausgeben. Wie kann man das umbauen, dass er alle ausgibt?

Navaria schrieb:

Wow rklm, vielen Dank fürs Optimieren. Zwei offensichtliche Fehler habe ich schon gefunden:

Gut!

1.) Ich seh den Sinn von

1 2	# Enable debugging via environment variable DEBUG [ -z "$DEBUG" ] || set -x

nicht, weil du die Variable $DEBUG nie abfragst, überhaupt verstehe ich die Zeile nicht. Erläuterung? ☺

Doch, sie wird ja genau an dieser Stelle abgefragt. Das siehst Du doch schon am Dollarzeichen. Schau Dir [ bzw. test an. Das Setzen ist das, was man hier nicht sieht. Das machst Du außerhalb. Entweder

1
2

$ export DEBUG=x
$ script

oder

1

$ DEBUG=y script

Letzteres hat den Vorteil, dass die Variable nur temporär belegt wird und nachher wieder ihren alten Wert hat. Aber sie wird an alle weiteren Prozesse vererbt. Wenn Du also mehrere Skripte hast, die sich gegenseitig aufrufen, werden alle mit dieser einen Variable in den Debugmodus versetzt.

2.) Die Variable $delfile ist ja offensichtlich ein Array aus Dateinamen /-pfaden.

1 2	cat <<LOG_HEADER >&9 DelFile: $delfile

würde aber ja nur den ersten Dateinamen /-pfad ausgeben. Wie kann man das umbauen, dass er alle ausgibt?

Das ist allerdings auch in Deiner Variante so. Einfach: Du ersetzt $delfile durch ${delfile[*]}. Ich würde das allerdings nur zu Debugzwecken ins Log schreiben - ansonsten eher nicht.

OK, nice. Aber hast du jetzt y und z vertauscht? 😀

Ah ich denke mal, du hast absichtlich z als Schalter für den Debug Modus verwendet, weil y zu ungewöhnlichen Resultaten kommt. Zumindest schaltet durch diese Zeile

1
2

# Enable debugging via environment variable DEBUG
[ -y "$DEBUG" ] || set -x

das dropbox_uploader Script sofort in den Debug Modus. Nimmt man z, dann passiert das nur, wenn den Debug-Schalter explizit beim Script-Aufruf startet. Also passt für mich.

So ich denke, ich hab jetzt alle Puzzleteile zusammen:

• Ich kann ein Script aus dem Script aufrufen

• Ich weiß jetzt, wie ich die zu löschenden Dateien finden kann

• Das uploaden in die Dropbox werde ich auch hinkriegen.

⇒ Daher schon mal: Vielen, vielen Dank für die super Hilfe!

Aber da ich Perfektionist bin und das Script vollständig verstehen möchte, hier noch drei Fragen zu diesem Block:

1
2
3
4
5
6
7

cat <<LOG_HEADER >&9
Backup Dir: $backup_dir
UsrDat Dir: $data_dir
DelFile: ${delfile[*]}
Log Dir: $log_dir
Logfile: $logfile
LOG_HEADER

1.) Ich würde diese Ausgabe gerne so bauen, dass sie nur erfolgt, wenn der Debug-Schalter gesetzt ist. Ich schätze mal das muss irgendwie so aussehen?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

if [ $DEBUG == 'y' ] || [ $DEBUG == 'x' ] # das hier geht bestimmt eleganter!
then
  cat <<LOG_HEADER >&9
  Backup Dir: $backup_dir
  UsrDat Dir: $data_dir
  DelFile: ${delfile[*]}
  Log Dir: $log_dir
  Logfile: $logfile
  LOG_HEADER
fi

2.) Die Ausgabe von DelFile: ${delfile[*]} ist nicht wirklich schön. Der reiht alle Dateinamen stumpf hintereinander weg. Hier stelle mir eine Schleife vor, die alle Dateinamen das Arrays auflistet, etwas so:

• DelFile^[0]: xxxxx

• DelFile^[1]: yyyyy

Wie muss die Schleife dafür aussehen?

3.) Ich hab den Sinn von

1
2
3
4

cat <<LOG_HEADER >&9
...
...
LOG_HEADER

noch nicht verstanden. Was soll das mit dem LOG_HEADER?

Navaria schrieb:

OK, nice. Aber hast du jetzt y und z vertauscht? 😀

Das ist für den Test egal. Bitte lies die Doku.

Navaria schrieb:

Ah ich denke mal, du hast absichtlich z als Schalter für den Debug Modus verwendet, weil y zu ungewöhnlichen Resultaten kommt. Zumindest schaltet durch diese Zeile

1 2	# Enable debugging via environment variable DEBUG [ -y "$DEBUG" ] || set -x

das dropbox_uploader Script sofort in den Debug Modus. Nimmt man z, dann passiert das nur, wenn den Debug-Schalter explizit beim Script-Aufruf startet. Also passt für mich.

Falsch, bitte lies die Doku und was ich vorher geschrieben habe.

So ich denke, ich hab jetzt alle Puzzleteile zusammen:

• Ich kann ein Script aus dem Script aufrufen

• Ich weiß jetzt, wie ich die zu löschenden Dateien finden kann

• Das uploaden in die Dropbox werde ich auch hinkriegen.

Das habe ich doch schon eingebaut (Zeile 29).

⇒ Daher schon mal: Vielen, vielen Dank für die super Hilfe!

Aber da ich Perfektionist bin und das Script vollständig verstehen möchte, hier noch drei Fragen zu diesem Block:

1 2 3 4 5 6 7

cat <<LOG_HEADER >&9 Backup Dir: $backup_dir UsrDat Dir: $data_dir DelFile: ${delfile[*]} Log Dir: $log_dir Logfile: $logfile LOG_HEADER

1.) Ich würde diese Ausgabe gerne so bauen, dass sie nur erfolgt, wenn der Debug-Schalter gesetzt ist. Ich schätze mal das muss irgendwie so aussehen?

1 2 3 4 5 6 7 8 9 10

if [ $DEBUG == 'y' ] || [ $DEBUG == 'x' ] # das hier geht bestimmt eleganter! then cat <<LOG_HEADER >&9 Backup Dir: $backup_dir UsrDat Dir: $data_dir DelFile: ${delfile[*]} Log Dir: $log_dir Logfile: $logfile LOG_HEADER fi

Nein. Nimm einfach den selben Test, den ich zum Einschalten benutzt habe.

2.) Die Ausgabe von DelFile: ${delfile[*]} ist nicht wirklich schön. Der reiht alle Dateinamen stumpf hintereinander weg. Hier stelle mir eine Schleife vor, die alle Dateinamen das Arrays auflistet, etwas so:

• DelFile^[0]: xxxxx

• DelFile^[1]: yyyyy

Wie muss die Schleife dafür aussehen?

Du iterierst genau so wie im Skript bei der Ermittlung der gelöschten - nur, dass der Schleifenrumpf anders aussieht.

3.) Ich hab den Sinn von

1 2 3 4

cat <<LOG_HEADER >&9 ... ... LOG_HEADER

noch nicht verstanden. Was soll das mit dem LOG_HEADER?

→ Here Doc → Doku.

Übrigens, vielleicht solltest Du Dir mal Borg Backup oder Restic anschauen. Die können auch remote sichern, nutzen Komprimierung und Verschlüsselung - aber vor allem Deduplikation, so dass ungeänderte Dateien nur einmal Platz beanspruchen und nicht in jedem Backup wie bei Dir mit tar.

rklm schrieb:

Übrigens, vielleicht solltest Du Dir mal Borg Backup oder Restic anschauen. Die können auch remote sichern, nutzen Komprimierung und Verschlüsselung - aber vor allem Deduplikation, so dass ungeänderte Dateien nur einmal Platz beanspruchen und nicht in jedem Backup wie bei Dir mit tar.

Ich hab's schon mal versucht, mich zu Borg schlau zu machen, aber ich hab's nicht verstanden ☹ Vor allem das Handling, wenn man doch mal was wiederherstellen muss, kam mir sehr sperrig vor. tar ist die Kanonen auf Spatzen Methode, aber ich kann damit umgehen. Das ist mir fast wichtiger als Speicherplatz zu sparen.

Navaria schrieb:

Ich hab's schon mal versucht, mich zu Borg schlau zu machen, aber ich hab's nicht verstanden ☹

Oh.

Vor allem das Handling, wenn man doch mal was wiederherstellen muss, kam mir sehr sperrig vor.

Bei Borg mountest Du einfach das Repo und kannst dann normal mit allen Tools darauf zugreifen wie auf ein reguläres Dateisystem. Total einfach - finde ich.

tar ist die Kanonen auf Spatzen Methode, aber ich kann damit umgehen. Das ist mir fast wichtiger als Speicherplatz zu sparen.

👍 Auch ein wichtiger Punk!

Hi again,

so ich habe jetzt einige Tage lang gepuzzled und herumprobiert und ich glaube ich bin kurz vor der Lösung des Problems.

Status: Es funktioniert fast alles, nur das Löschen der Dateien in der Dropbox hakt noch. Das Problem ist, dass ich beim Löschen die Syntax dropbox_uploader.sh delete <REMOTE_FILE/DIR> verwenden muss, was in deinem Löschscript noch nicht berücksichtigt ist.

Mein Script aktuell:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

#!/bin/bash

# Enable debugging via environment variable DEBUG
# Einschalten mit DEBUG=z oder DEBUG=x
# Der Debug-Modus wird extern bei Scriptaufruf gesetzt. Es gibt 2 Varianten:
# 1. export DEBUG=x
#    ./<Script.sh>
# oder
# 2. DEBUG=z ./<Script.sh>
# Letzteres hat den Vorteil, dass die Variable nur temporär belegt wird und nachher 
# wieder ihren alten Wert hat. Aber sie wird an alle weiteren Prozesse vererbt. 
# Wenn Du also mehrere Skripte hast, die sich gegenseitig aufrufen, werden alle mit 
# dieser einen Variable in den Debugmodus versetzt.
[ -z "$DEBUG" ] || set -x

# Variablen deklarieren
date=$(date +"%Y-%m-%d")
datetime=$(date '+%Y-%m-%d_%H%M%S')
backup_base="$HOME/foundry/backup/vtt1"
backup_dir="$backup_base/testdata"
backup_file="$backup_dir/backupData_$datetime.tar.gz"
dropbox_base="markus/vtt1"
dropbox_dir="$dropbox_base/testdata"
del_file=("$backup_dir"/*)
data_dir="$HOME/foundry/server/vtt1/foundrydata"
log_dir="$HOME/foundry/logs/vtt1/backuplogs"
log_file="$log_dir/dpTest3_$datetime.log"

# Timestamp-Funktion. Setzt einen aktuellen Timestamp vor die Ausgabezeile.
# Siehe https://serverfault.com/questions/310098/how-to-add-a-timestamp-to-bash-script-log
timestamp() {
    while IFS= read -r line; do
	  printf "%s %s\n" "$(date +"%Y-%m-%d %H:%M:%S")" "$line";
    done
}

# Open log
exec 9>>"$log_file"

# Inhalt Dropbox auflisten 
echo == PHASE 0 == List Dropbox directory before uploading... | timestamp >&9
./dropbox_uploader.sh list markus/vtt1/testdata | timestamp >&9
echo List Dropbox directory done. | timestamp >&9

# Backup erstellen
echo == PHASE 1 == Creating backup file... | timestamp >&9
# tar -czvf "$backup_file" "$data_dir" "$(realpath --relative-to ../dummy "$data_dir")" | timestamp >&9
echo Finished creating backup file. | timestamp >&9

# Alte Backups entfernen
echo == PHASE 2 == Deleting old backup files... | timestamp >&9
find "$backup_dir"/*.tar.gz -type f -mtime +7 -delete -print  | timestamp >&9
echo Finished deleting old backup files. | timestamp >&9

# Backup-Dateien in Dropbox hochladen, existierende Dateien ignorieren
echo == PHASE 3 == Start Dropbox upload, ignoring files with already existing filenames... | timestamp >&9
./dropbox_uploader.sh -s upload $backup_dir $dropbox_base | timestamp >&9
echo Dropbox Upload done. | timestamp >&9

# Gelöschte Backup-Dateien auch in der Dropbox löschen
echo == PHASE 4 == Deleting old backup files in Dropbox as well ... | timestamp >&9
for f in "${del_file[@]}"; do
  [ -e "$f" ] || ./dropbox_uploader.sh delete $f | timestamp >&9
done

# Inhalt Dropbox auflisten (zum Vergleich)
echo == PHASE 5 == List Dropbox directory after uploading: | timestamp >&9
./dropbox_uploader.sh list markus/vtt1/testdata | timestamp >&9
echo List Dropbox directory done. | timestamp >&9

Und die Log-Ausgabe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

2023-09-24 16:29:26 == PHASE 0 == List Dropbox directory before uploading...
2023-09-24 16:29:28  > Listing "/markus/vtt1/testdata"... DONE
2023-09-24 16:29:28  [F] 1681503086 backupData_2023-08-29_040001.tar.gz
2023-09-24 16:29:28  [F] 1698234267 backupData_2023-09-05_040001.tar.gz
2023-09-24 16:29:28  [F] 1698609390 backupData_2023-09-19_040001.tar.gz
2023-09-24 16:29:28  [F] 200541763  backupServer_2023-09-19_043001.tar.gz
2023-09-24 16:29:28  [F] 1700650656 backupData_2023-09-24_152846.tar.gz
2023-09-24 16:29:28 List Dropbox directory done.
2023-09-24 16:29:28 == PHASE 1 == Creating backup file...
2023-09-24 16:29:28 Finished creating backup file.
2023-09-24 16:29:28 == PHASE 2 == Deleting old backup files...
2023-09-24 16:29:28 /home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz
2023-09-24 16:29:28 /home/markus/foundry/backup/vtt1/testdata/backupData_2023-09-05_040001.tar.gz
2023-09-24 16:29:28 Finished deleting old backup files.
2023-09-24 16:29:28 == PHASE 3 == Start Dropbox upload, ignoring files with already existing filenames...
2023-09-24 16:29:30  > Creating Directory "/markus/vtt1/testdata"... ALREADY EXISTS
2023-09-24 16:29:31  > Skipping already existing file "/markus/vtt1/testdata/backupData_2023-09-19_040001.tar.gz"
2023-09-24 16:29:32  > Skipping already existing file "/markus/vtt1/testdata/backupData_2023-09-24_152846.tar.gz"
2023-09-24 16:29:32 Dropbox Upload done.
2023-09-24 16:29:32 == PHASE 4 == Deleting old backup files in Dropbox as well ...
2023-09-24 16:29:34  > Deleting "/home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz"... FAILED
2023-09-24 16:29:34 Some error occured. rerun the script with "-d" option and check the output and logfile: /tmp/du_resp_24160.
2023-09-24 16:29:35  > Deleting "/home/markus/foundry/backup/vtt1/testdata/backupData_2023-09-05_040001.tar.gz"... FAILED
2023-09-24 16:29:35 Some error occured. rerun the script with "-d" option and check the output and logfile: /tmp/du_resp_15298.
2023-09-24 16:29:35 == PHASE 5 == List Dropbox directory after uploading:
2023-09-24 16:29:36  > Listing "/markus/vtt1/testdata"... DONE
2023-09-24 16:29:36  [F] 1681503086 backupData_2023-08-29_040001.tar.gz
2023-09-24 16:29:36  [F] 1698234267 backupData_2023-09-05_040001.tar.gz
2023-09-24 16:29:36  [F] 1698609390 backupData_2023-09-19_040001.tar.gz
2023-09-24 16:29:36  [F] 200541763  backupServer_2023-09-19_043001.tar.gz
2023-09-24 16:29:36  [F] 1700650656 backupData_2023-09-24_152846.tar.gz
2023-09-24 16:29:36 List Dropbox directory done.

Das Problem ist also diese Zeile

1
2
3

for f in "${del_file[@]}"; do
  [ -e "$f" ] || ./dropbox_uploader.sh delete $f | timestamp >&9
done

weil das Script hier den vollen Pfad auf meinem Raspberry Pi "/home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz" verwendet, ich dem Script aber "markus/vtt1/testdata/backupData_2023-08-29_040001.tar.gz" übergeben muss.

Hast du eine Idee, rklm?

Edit: Das Erstellen des Backups in Phase 1 ist für Testzwecke auskommentiert, weil ich nicht bei jedem Test ein neues Backupfile brauche. Ich kopiere aber immer "frisch" alte Backup-Dateien in das /testdata Verzeichnis, damit auch immer was zum Löschen da ist

Navaria schrieb:

Das Problem ist also diese Zeile

1 2 3

for f in "${del_file[@]}"; do [ -e "$f" ] || ./dropbox_uploader.sh delete $f | timestamp >&9 done

weil das Script hier den vollen Pfad auf meinem Raspberry Pi "/home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz" verwendet, ich dem Script aber "markus/vtt1/testdata/backupData_2023-08-29_040001.tar.gz" übergeben muss.

Hast du eine Idee, rklm?

Klar. Das ist sollte so gehen:

1
2
3

for f in "${del_file[@]}"; do
  [ -e "$f" ] || ./dropbox_uploader.sh delete "$(id -un)/$(realpath -e "--relative-to=$HOME/foundry/backup" "$f")" | timestamp >&9
done

da scheint noch was im Argen zu sein:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

2023-09-24 20:29:08 Finished creating backup file.
2023-09-24 20:29:08 == PHASE 2 == Deleting old backup files...
2023-09-24 20:29:08 /home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz
2023-09-24 20:29:08 /home/markus/foundry/backup/vtt1/testdata/backupData_2023-09-05_040001.tar.gz
2023-09-24 20:29:08 Finished deleting old backup files.
2023-09-24 20:29:08 == PHASE 3 == Start Dropbox upload, ignoring files with already existing filenames...
2023-09-24 20:29:10  > Creating Directory "/markus/vtt1/testdata"... ALREADY EXISTS
2023-09-24 20:29:11  > Skipping already existing file "/markus/vtt1/testdata/backupData_2023-09-19_040001.tar.gz"
2023-09-24 20:29:13  > Skipping already existing file "/markus/vtt1/testdata/backupData_2023-09-24_152846.tar.gz"
2023-09-24 20:29:13 Dropbox Upload done.
2023-09-24 20:29:13 == PHASE 4 == Deleting old backup files in Dropbox as well ...
2023-09-24 20:29:14  > Deleting "/markus/"... FAILED
2023-09-24 20:29:14 Some error occured. rerun the script with "-d" option and check the output and logfile: /tmp/du_resp_20462.
2023-09-24 20:29:15  > Deleting "/markus/"... FAILED
2023-09-24 20:29:15 Some error occured. rerun the script with "-d" option and check the output and logfile: /tmp/du_resp_22988.

Auf der Konsole kamen folgende Meldungen:

1
2

realpath: /home/markus/foundry/backup/vtt1/testdata/backupData_2023-08-29_040001.tar.gz: Datei oder Verzeichnis nicht gefunden
realpath: /home/markus/foundry/backup/vtt1/testdata/backupData_2023-09-05_040001.tar.gz: Datei oder Verzeichnis nicht gefunden

Ich schätze mal realpath funktioniert hier nicht mehr, weil die Dateien ja bereits weiter oben gelöscht wurden.