Beiträge von V-Treiber
-
-
Ich sehe, wir verstehen uns! Wahrscheinlich erinnerst Du Dich auch noch an debug g-c800:5. 
Nein, es soll nicht zwischen Partitionen auf ein und der selben Platte kopiert werden, jedenfalls nicht parallel. Bei HDDs, ganz besonders externen, ist die mechanische Kopfbewegung der begrenzende Faktor, wobei das bei großen Dateien ob der Pufferung auch nicht so ins Gewicht fällt.
Mir geht es mehr um die Puffer, die rsync anlegt und ob die Jobs auf die Kerne verteilt werden.

-
Ich kopiere/verschiebe regelmäßig große Dateien (zwischen 200 und 300GB) zwischen Partitionen. Dafür schmeiße ich abends den rsync an. Das würde ich gerne in einem script weitestgehend parallelisieren.
Eckdaten:
4-Kern 3500er AMD64,
32 GB RAM
2 SSD 500GB
2 externe HDD 1TB
Plan bash-script
Ich finde nichts zu Zuverlässiges dazu, wie viele ich parallel starten kann.
Ich meine ursprünglich war das mal für das synchronisieren von Serverdaten geschrieben, trotzdem ...
-
Die Alternative wäre, vor den Patentinhabern zu Kreuze zu kriechen und Mondpreise für Patente abzudrücken.
H264 ist Anfang 2025 weltweit ausgelaufen und seit Juli 2026 komplett Patentfrei, H265 wird noch ein paar Jahre dauern.
-
nö ich entschuldige nicht, denn ich habe schon alles mögliche eingegrenzt. Und was du damit in diesem Zusammenhang sagen willst ist auch absolut nicht klar.
Du brauchst nichts zu entschuldigen, ich sag nur, Textverständnis. Ob Du meinen Rat, den Du nicht verstehst annimmst oder nicht, ist mir eigentlich so lang wie breit.

Woher willst Du wissen, das bei der Auflösung der Abhängigkeiten nicht etwas schiefgelaufen ist?
-
jetzt nochmal ein zypper dup? Wenn ja vom aktuellen stand, oder vorher ein rollback zum Stand vor den Problemen? Gibt es noch irgendwelche Optionen für zypper dup, die du empfehlen würdest?
stimmt, hab ich übersehen. Aber dass das die Ursache für das Problem ist ist nahezu ausgeschlossen. Denn Packman hat nichts mit Palsma zu tun.
Sorry, das ich mich einmische, aber ...
Mit Fehler einkreisen hast Du es nicht so oder?
Üblicherweise geht man nach dem Ausschluß-Verfahren vor. D.h. man schmeißt erst ein Mal alles raus, was voraussichtlich nicht die Ursache ist. Das macht das Ganze übersichtlicher.
Dann schmeißt man alles raus was doppelt. ist Danach bleibt meist nur eine Handvoll Möglichkeiten über. Die kann man dann durchtesten.
Wenn Du mit Deiner Methode Fehler in einem Code suchen würdest, ...
-
Nö, du häätets statt dem symlink den Timer und den service dorthin verschieben müssen, den Rest erledigt dann systemd.
Codethosto@localhost:/> ls /etc/systemd/system/my* /etc/systemd/system/my-backup.service /etc/systemd/system/my-backup.timer.service stand in .../system und .timer in .../system/timers.targets.wants, war damit kein symlink und wird ignoriert. Der Hinweis von luigi hat dazu geführt, das ich mir das Ganze mal genauer angeguckt habe und siehe da...
OT: Mein Frau schimpft gerade laut und ausführlich über Winzigweich.

-
Und bei hochwertigem SCSI-Raid würde ich erwarten, dass die Firmware zwischen einem RAID-Member und einer frischen Platte unterscheiden kann, wenn es um die Richtung der Spiegelung geht

Nun, Netware 3.12 hatte zwei Möglichkeiten, über einen RAID-Kontroller oder über Mirroring/Duplexing in Netware.
Öffentlicher Auftraggeber mit einem Hobby-Admin, da kannst Du reden, was Du willst. Die von mir empfohlene Variante mit Adaptec oder Vortex RAID scheitert dann an den Kosten, selbst für ein Duplexing gab es kein Geld
Platte kaputt, zu mir geschickt, ich mit neuer Platte hin, eingebaut und dann ging es los. Ende vom Lied: Netware neu von Disketten installiert, Bandsicherung (natürlich GFS) zurückgespielt, Spiegel neu eingerichtet.
Den Laden gibt es sogar noch. -
Dann ersetz halt zum Testen dein Shellscript durch etwas harmloses ... ?
Nö, ich habe doch gesagt Du hast mich auf eine Idee gebracht.
Code
Alles anzeigenthosto@localhost:/> sudo mv /etc/systemd/system/timers.target.wants/my-backup.timer /etc/systemd/system/my-backup.timer [sudo] Passwort für root: thosto@localhost:/> sudo systemctl enable my-backup.timer Created symlink '/etc/systemd/system/timers.target.wants/my-backup.timer' → '/etc/systemd/system/my-backup.timer'. thosto@localhost:/> systemctl list-timers --al NEXT LEFT LAST PASSED UNIT ACTIVATES Fri 2026-08-28 15:00:00 CEST 14min Fri 2026-08-28 14:00:00 CEST 45min ago snapper-timeline.timer snapper-timeline.service Fri 2026-08-28 15:00:00 CEST 14min Fri 2026-08-28 14:00:00 CEST 45min ago snapper-cleanup.timer snapper-cleanup.service Fri 2026-08-28 20:09:05 CEST 5h 24min Thu 2026-08-27 20:09:05 CEST 18h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sat 2026-08-29 00:00:00 CEST 9h Fri 2026-08-28 00:00:00 CEST 14h ago mlocate.timer mlocate.service Sat 2026-08-29 00:22:50 CEST 9h Fri 2026-08-28 00:27:05 CEST 14h ago logrotate.timer logrotate.service Sat 2026-08-29 01:36:11 CEST 10h Fri 2026-08-28 01:42:05 CEST 13h ago check-battery.timer check-battery.service Sat 2026-08-29 01:36:48 CEST 10h Fri 2026-08-28 00:13:05 CEST 14h ago backup-rpmdb.timer backup-rpmdb.service Sat 2026-08-29 01:50:20 CEST 11h Fri 2026-08-28 01:05:31 CEST 13h ago backup-sysconfig.timer backup-sysconfig.service Sat 2026-08-29 02:07:09 CEST 11h Fri 2026-08-28 01:01:00 CEST 13h ago man-db.timer man-db.service Mon 2026-08-31 00:00:00 CEST 2 days Mon 2026-08-24 00:00:00 CEST 4 days ago btrfs-balance.timer btrfs-balance.service Mon 2026-08-31 00:31:17 CEST 2 days Mon 2026-08-24 00:01:05 CEST 4 days ago fstrim.timer fstrim.service Tue 2026-09-01 00:00:00 CEST 3 days Sat 2026-08-01 00:00:09 CEST - btrfs-scrub.timer btrfs-scrub.service Tue 2026-09-01 00:00:08 CEST 3 days Sat 2026-08-22 15:18:45 CEST - wtmpdb-rotate.timer wtmpdb-rotate.service - - - - mandb.timer - - - - - my-backup.timer my-backup.service - - - - openSUSE-build-key-import.timer openSUSE-build-key-import.serviceDas entscheidende Stichwort war der Sym-link.
Danke. -
ich weiß, der macht dann aber im laufenden Betrieb ein Backup, das ist
Und da die Bash, wie oben beschrieben Dateien kopiert und "alte" Backups löscht....könnte ein systemctl stop schon zu spät sein.