Lost a cluster?

[rotech1]

I see the last couple of days the two machines we have running cyphertite are both attempting a FULL BACKUP. Normally its a quick incremental ... I don't see why it would be doing a full backup again, unless the originals got lost.

More troubling, one of the two has been stuck for a whole day with no progress.

Not sure what I should do about it, on my end...

[SirHumphreyAppleby]

Changed files being stuck is a known issue which was being worked on last week (Issue #102).

I am hoping to see a verify option added soon (Issue #101) so we can verify archives. Because backups do not offer an easily-accessible file revision history, it's desirable not to backup unless we know something has changed. The risk is, if data is lost on the remote server, we won't know until we try to restore the backup.

[rotech1]

Took about 8 hours to "stop" the stuck backups in progress, but after they finally stopped, the next four runs seemed to go though OK - followed by a "failed to connect" yesterday.

I'm not quite sure if the occassional "failed to connect" to Cyphertite might actually be some issue with our local connection. (I'll have to set up some sort of external ping-test to be sure…)

best regards, Michael

From: SirHumphreyAppleby [mailto:notifications@github.com]
Sent: Sunday, April 19, 2015 16:58 PM
To: conformal/cyphertite
Cc: Michael Walker - Rotech
Subject: Re: [cyphertite] Lost a cluster? (#116)

Changed files being stuck is a known issue which was being working on last week (Issue #102#102).

I am hoping to see a verify option added soon (Issue #101#101) so we can verify archives. Because backups do not offer an easily-accessible file revision history, it's desirable not to backup unless we know something has changed. The risk is, if data is lost on the remote server, we won't know until we try to restore the backup.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/116#issuecomment-94326680.