Datei landet in falschem cache pool

[guboehm]

Moin zusammen,

 

ich habe zwei cache pools

• cache (für alles mögliche)
• cache_vm_docker (appdata, etc)

 

sowie zwei shares

• backup
  • primary storage: cache
  • secondary storage: arry
  • mover action: cache -> array
• appdata
  • primary storage: cache_vm_docker
  • secondary storage: array
  • mover action: array -> cache_vm_docker

 

Nun habe ich ein Skript, welches ein Backup eines SQL Containers nach /mnt/user/appdata/mssql-production/backup (cache_vm_docker) schreibt.

Dann greift sich das Skript dieses Backup und verschiebt es nach /mnt/user/backup/backup-wawi (cache)

 

So, und hier beginnt meine Verwunderung:

 

Die Location ist offensichtlich 'cache_vm_docker', obwohl /mnt/user/backup/backup-wawi ja eigentlich 'cache' nutzen müsste.

Nach dem Verschieben wird die Datei gezippt. Die tmp Datei ziBwWY9 liegt dann auch wieder ordentlich auf 'cache'.

 

Im Prinzip stört mich das nicht, insbesondere, da ja nach dem Zippen alles da liegt, wo es hingehört. Was ich mich allerdings frage

1. ist das so richtig, dass die Datei erstmal im Falschen cache pool landet
2. würde der mover die Datei dann trotzdem ins Array verschieben? 

 

Hier noch das kurze Skript:

#!/bin/bash

# Define the path to your BackupScript.sh on the host
host_script_path="/mnt/user/misc/scripts/BackupMSSQLdatabases.sql"
container_script_path="/home"

# define backup locations
host_backup_path="/mnt/user/appdata/mssql-production/backup"
backup_share="/mnt/user/backup/backup-wawi"

# Specify the name or ID of your MSSQL container
container_name="MS-SQL-Server-Production"

docker cp "$host_script_path" "$container_name":"$container_script_path"
docker exec "$container_name" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P xxxxx -i /home/BackupMSSQLdatabases.sql

# move files to central backup share
mv "$host_backup_path"/*.bak "$backup_share/"

 

[Mainfrezzer]

Benutze statt /user/ die disks direkt.

 

#!/bin/bash

# Define the path to your BackupScript.sh on the host
host_script_path="/mnt/user/misc/scripts/BackupMSSQLdatabases.sql"
container_script_path="/home"

# define backup locations
host_backup_path="/mnt/cache_vm_docker/appdata/mssql-production/backup"
backup_share="/mnt/cache/backup/backup-wawi"

# Specify the name or ID of your MSSQL container
container_name="MS-SQL-Server-Production"

docker cp "$host_script_path" "$container_name":"$container_script_path"
docker exec "$container_name" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P xxxxx -i /home/BackupMSSQLdatabases.sql

# move files to central backup share
mv "$host_backup_path"/*.bak "$backup_share/"

 

[guboehm]

hmmmm, OK. Ich muss gestehen, dass ich noch nicht ganz verstanden habe, wann man die disks direkt ansprechen soll und wann nur die shares.

Wenn ich in diesem Fall die Datei(en) direkt auf eine meiner Disks schreiben würde, hätte ich aber keine Kontrolle mehr darüber, ob sie ggfs. keinen Platz mehr hat., oder? Das würde doch mit dem Schreiben in den Share umgangen werden, da sich ja dann der mover darum kümmert, alles dahin zu packen, wo noch Platz ist.

 

Aber das erklärt ja auch nicht das gesehene Verhalten. Wie gesagt, stören tut mich das nicht wirklich, möchte es nur gerne verstehen...

[Mainfrezzer]

FUSE ist nen bisschen funky.

Wenn man /user/ benutzen möchte dann müsste man statt "mv" "cp" nehmen und dann anschließen die original Dateien löschen.

 

#!/bin/bash

# Define the path to your BackupScript.sh on the host
host_script_path="/mnt/user/misc/scripts/BackupMSSQLdatabases.sql"
container_script_path="/home"

# define backup locations
host_backup_path="/mnt/user/appdata/mssql-production/backup"
backup_share="/mnt/user/backup/backup-wawi"

# Specify the name or ID of your MSSQL container
container_name="MS-SQL-Server-Production"

docker cp "$host_script_path" "$container_name":"$container_script_path"
docker exec "$container_name" /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P xxxxx -i /home/BackupMSSQLdatabases.sql

# move files to central backup share
cp "$host_backup_path"/*.bak "$backup_share/"
rm "$host_backup_path"/*.bak

 

Edited September 21, 2023 by Mainfrezzer

[guboehm]

ok, damit könnte ich leben 🙂