rsnync cache(???) Fehler

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
letzter3
Beiträge: 446
Registriert: 16.07.2011 22:07:31

rsnync cache(???) Fehler

Beitrag von letzter3 » 12.02.2017 11:41:49

Hallo zusammen,

ich sichere per pull täglich Datenbankbackups.
Momentan mit -vv

Code: Alles auswählen

rsync -avv --delete -e "ssh -i /root/.ssh/id_rsa" root@"ÖFFENTLICHE-ADRESSE:/home/backup /media/347ded30-d521-4d0a-a6e5-ceb36a77a121/PT_LWL_BAckup/
Ich bekomme beispielsweise um 06:32 Uhr folgenden Fehler per mail gemeldet:
rsync: stat "/media/347ded30-d521-4d0a-a6e5-ceb36a77a121/PT_LWL_BAckup/backup/daily/ptlwl/.daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.GuMmAk" failed: No such file or directory (2)
rsync: rename "/media/347ded30-d521-4d0a-a6e5-ceb36a77a121/PT_LWL_BAckup/backup/daily/ptlwl/.daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.GuMmAk" -> "backup/daily/ptlwl/daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2": No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [generator=3.0.9]
Allerdings gibt mir cron ebenfalls folgende Info per mail zur selben Uhrzeit:
opening connection using: ssh -i /root/.ssh/id_rsa -l root ÖFFENTLICHE-ADRESSE

rsync --server --sender -vvlogDtpre.iLsf . /home/backup
receiving incremental file list
delta-transmission enabled
backup/ERRORS_localhost-984376720.log is uptodate
backup/localhost-981528578.log is uptodate
deleting backup/daily/ptlwl/.daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.l0MlKB
backup/daily/ptlwl/daily_ptlwl_2017-02-06_00h50m_Monday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-07_00h28m_Tuesday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-08_00h43m_Wednesday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-09_00h35m_Thursday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-09_23h38m_Thursday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-10_23h32m_Friday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-07_00h28m_Tuesday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-08_00h43m_Wednesday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-09_00h35m_Thursday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-09_23h38m_Thursday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-10_23h32m_Friday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-07_00h28m_Tuesday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-08_00h43m_Wednesday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-09_00h35m_Thursday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-09_23h38m_Thursday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-10_23h32m_Friday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-11_23h52m_Saturday.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2016-11-01_00h46m_November.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2016-12-01_00h47m_December.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2017-01-01_00h51m_January.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2017-02-01_00h44m_February.sql.bz2 is uptodate
backup/monthly/mysql/monthly_mysql_2015-10-01_00h40m_October.sql.bz2 is uptodate
backup/monthly/performance_schema/monthly_performance_schema_2015-10-01_00h40m_October.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2016-11-01_00h46m_November.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2016-12-01_00h47m_December.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2017-01-01_00h51m_January.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2017-02-01_00h44m_February.sql.bz2 is uptodate
backup/monthly/ptlwltest/monthly_ptlwltest_2015-10-01_00h40m_October.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2016-11-01_00h46m_November.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2016-12-01_00h47m_December.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2017-01-01_00h51m_January.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2017-02-01_00h44m_February.sql.bz2 is uptodate
backup/status/status_daily_2017-02-07_00h28m_Tuesday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-08_00h43m_Wednesday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-09_00h35m_Thursday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-09_23h38m_Thursday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-10_23h32m_Friday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-11_23h52m_Saturday.txt.bz2 is uptodate
backup/status/status_monthly_2016-11-01_00h46m_November.txt.bz2 is uptodate
backup/status/status_monthly_2016-12-01_00h47m_December.txt.bz2 is uptodate
backup/status/status_monthly_2017-01-01_00h51m_January.txt.bz2 is uptodate
backup/status/status_monthly_2017-02-01_00h44m_February.txt.bz2 is uptodate
backup/daily/ptlwl/
backup/daily/ptlwl/daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2
backup/daily/ptpch/
backup/daily/ptpch/daily_ptpch_2017-02-11_23h52m_Saturday.sql.bz2
total: matches=0 hash_hits=0 false_alarms=0 data=956856763

sent 241 bytes received 956976403 bytes 43642.76 bytes/sec
total size is 11391398819 speedup is 11.90
und um 06:20 Uhr ebenfalls
opening connection using: ssh -i /root/.ssh/id_rsa -l root 7oq4sdcmo4lcojpu.myfritz.net rsync --server --sender -vvlogDtpre.iLsf . /home/backup
receiving incremental file list
delta-transmission enabled
backup/ERRORS_localhost-984376720.log is uptodate
backup/localhost-981528578.log is uptodate
deleting backup/daily/ptlwl/.daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.GuMmAk
backup/daily/ptlwl/daily_ptlwl_2017-02-06_00h50m_Monday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-07_00h28m_Tuesday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-08_00h43m_Wednesday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-09_00h35m_Thursday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-09_23h38m_Thursday.sql.bz2 is uptodate
backup/daily/ptlwl/daily_ptlwl_2017-02-10_23h32m_Friday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-07_00h28m_Tuesday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-08_00h43m_Wednesday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-09_00h35m_Thursday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-09_23h38m_Thursday.sql.bz2 is uptodate
backup/daily/ptpch/daily_ptpch_2017-02-10_23h32m_Friday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-07_00h28m_Tuesday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-08_00h43m_Wednesday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-09_00h35m_Thursday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-09_23h38m_Thursday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-10_23h32m_Friday.sql.bz2 is uptodate
backup/fullschema/fullschema_daily_2017-02-11_23h52m_Saturday.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2016-11-01_00h46m_November.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2016-12-01_00h47m_December.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2017-01-01_00h51m_January.sql.bz2 is uptodate
backup/fullschema/fullschema_monthly_2017-02-01_00h44m_February.sql.bz2 is uptodate
backup/monthly/mysql/monthly_mysql_2015-10-01_00h40m_October.sql.bz2 is uptodate
backup/monthly/performance_schema/monthly_performance_schema_2015-10-01_00h40m_October.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2016-11-01_00h46m_November.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2016-12-01_00h47m_December.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2017-01-01_00h51m_January.sql.bz2 is uptodate
backup/monthly/ptlwl/monthly_ptlwl_2017-02-01_00h44m_February.sql.bz2 is uptodate
backup/monthly/ptlwltest/monthly_ptlwltest_2015-10-01_00h40m_October.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2016-11-01_00h46m_November.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2016-12-01_00h47m_December.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2017-01-01_00h51m_January.sql.bz2 is uptodate
backup/monthly/ptpch/monthly_ptpch_2017-02-01_00h44m_February.sql.bz2 is uptodate
backup/status/status_daily_2017-02-07_00h28m_Tuesday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-08_00h43m_Wednesday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-09_00h35m_Thursday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-09_23h38m_Thursday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-10_23h32m_Friday.txt.bz2 is uptodate
backup/status/status_daily_2017-02-11_23h52m_Saturday.txt.bz2 is uptodate
backup/status/status_monthly_2016-11-01_00h46m_November.txt.bz2 is uptodate
backup/status/status_monthly_2016-12-01_00h47m_December.txt.bz2 is uptodate
backup/status/status_monthly_2017-01-01_00h51m_January.txt.bz2 is uptodate
backup/status/status_monthly_2017-02-01_00h44m_February.txt.bz2 is uptodate
backup/daily/ptlwl/
backup/daily/ptlwl/daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2
backup/daily/ptpch/daily_ptpch_2017-02-11_23h52m_Saturday.sql.bz2
total: matches=0 hash_hits=0 false_alarms=0 data=1050163643

sent 241 bytes received 1050294676 bytes 50830.97 bytes/sec
total size is 11484705699 speedup is 10.93
Das ganze wiederholt sich alle 2 1/2 Stunden, es wechselt nur die Endung daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.GuMmAk bzw. dann irgendwann das komplette file und dann wieder die Endung.
Das Datenbankbackup wird per automysqlbackup täglich um 23:25 Uhr angestossen und ist zwischen 23:30 und 23:50 zu Ende, der rsync cron täglich um 21:09 Uhr.
Die für ein backup untypische Reihenfolge habe ich momentan gewählt, damit der Datenbankdump auch definitiv vor dem rsync fertig ist.

Der Datenbankserver ist ein Debian

Code: Alles auswählen

letzter@ptLWL01:~$ uname -ar
Linux ptLWL01 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64 GNU/Linux

letzter@ptLWL01:~$ cat /etc/debian_version
7.11
letzter@ptLWL01:~$ 
Der rsync-ziehende ist ein OpenMediaVault 2.2.13

Wie bekomme ich die Fehlermeldung weg (ausser sie einfach zu löschen :-))

Benutzeravatar
detix
Beiträge: 1702
Registriert: 07.02.2007 18:51:28
Wohnort: MK

Re: rsnync cache(???) Fehler

Beitrag von detix » 12.02.2017 14:29:22

letzter3 hat geschrieben:

Code: Alles auswählen

rsync -avv --delete -e "ssh -i /root/.ssh/id_rsa" root@"ÖFFENTLICHE-ADRESSE:/home/backup /media/347ded30-d521-4d0a-a6e5-ceb36a77a121/PT_LWL_BAckup/
Ohne große Ahnung zu haben: du hast die 3 Hochkommatas tatsächlich so gesetzt?
Gruß an alle Debianer, und immer daran denken:
Macht ohne Haftung funktioniert nicht!

letzter3
Beiträge: 446
Registriert: 16.07.2011 22:07:31

Re: rsnync cache(???) Fehler

Beitrag von letzter3 » 12.02.2017 14:46:08

Nein, Fehler beim Ersetzen der Adresse. :roll:
Korrekterweise so:

Code: Alles auswählen

rsync -avv --delete -e "ssh -i /root/.ssh/id_rsa" root@ÖFFENTLICHE-ADRESSE:/home/backup /media/347ded30-d521-4d0a-a6e5-ceb36a77a121/PT_LWL_BAckup/
Michael

schwedenmann
Beiträge: 5528
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: rsnync cache(???) Fehler

Beitrag von schwedenmann » 12.02.2017 15:13:38

Hallo


Lief das das denn mal korrekt ?

Ansonsten rsync --delete -avze ssh.....

oder wozu soll -avv gut sein ?

mfg
schwedenmann

letzter3
Beiträge: 446
Registriert: 16.07.2011 22:07:31

Re: rsnync cache(???) Fehler

Beitrag von letzter3 » 12.02.2017 15:25:38

schwedenmann hat geschrieben: Lief das das denn mal korrekt ?
Der sync als solcher läuft ja korrekt. Alle zu syncenden files sind da.
Es wird eine versteckte Datei (sicherlich aus irgendeinem dump-Vorgang) als fehlend angemeckert.
Das dürfte aber bei den eingestellten dump-/sync-Zeiten nicht vorkommen.

Früher hatte ich dump/sync möglicherweise zu schnell hintereinander, sodass der dump möglicherweise noch nicht fertig war.
Ich vermute, das rsync daher noch irgendwo im cache hat, finde da aber nix.
schwedenmann hat geschrieben: oder wozu soll -avv gut sein ?
-a und 2 x -v -> für absolut gesprächig. Will ja output haben, der bei der Fehlersuche hilft.


Korrektur, es sind nicht alle files da.
Zuletzt geändert von letzter3 am 12.02.2017 15:36:51, insgesamt 1-mal geändert.

Benutzeravatar
Dogge
Beiträge: 1895
Registriert: 13.09.2010 11:07:33
Lizenz eigener Beiträge: MIT Lizenz

Re: rsnync cache(???) Fehler

Beitrag von Dogge » 12.02.2017 15:34:47

failed: No such file or directory
Diese Fehlermeldung kenne ich, wenn Dateien während des Backups auf dem Quellsystem gelöscht werden.
Debian Testing + Gnome | Linux-Anfänger seit 04/2003
http://files.mdosch.de/2014-07/0xE13D657D.asc

letzter3
Beiträge: 446
Registriert: 16.07.2011 22:07:31

Re: rsnync cache(???) Fehler

Beitrag von letzter3 » 12.02.2017 15:41:45

Diese Fehlermeldung kenne ich, wenn Dateien während des Backups auf dem Quellsystem gelöscht werden.
Ja, das passiert "irgendwie"

Code: Alles auswählen

.daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.GuMmAk

deleting .... .daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.l0MlKB

rename ".... .daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2.GuMmAk -> daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2"
Allerdings existiert daily_ptlwl_2017-02-11_23h52m_Saturday.sql.bz2 im Sicherungsordner (rsync-Ziel)

Dürfte aber nicht bei den Startzeiten der scripts.
Das dump-script ist hier um 23:52 Uhr zu ende, das backup script läuft am nächsten Tag um 21:09 Uhr.
Es sei denn der upload dauert mehr als 2 Stunden......
Wäre möglich, die DB ist komprimiert ca. 600 MB....
Werd mal den sync ne Stunde nach vorne verlagern.

Ob ich einfach mal die logs

Code: Alles auswählen

backup/ERRORS_localhost-984376720.log is uptodate
backup/localhost-981528578.log is uptodate
lösche?

Antworten