search

Mondane / timebackup

A backup like OS X timemachine for Linux/Cygwin
8 stars 3 forks source link

Rossica #2

Closed rossica closed 9 years ago

rossica commented 10 years ago
  1. Added support for unique log files for each backup. The goal is to prevent having one giant log file after a few months of back ups. To correlate any errors experienced with the backup folder that had the error, the log file date and folder date are the same.
  2. The script will now link against any previous incomplete backup. If a back up client has a lot of data to back up and a slow upload speed coupled with unreliable internet connectivity, this will enable the client to complete their back up eventually. Previously, the client would start from scratch every attempt, which means the client needs no (connectivity) issues for the (sometimes long) duration of the backup, in order to successfully back up any data; it's all or nothing. Now, if there is an error, or if the connectivity between client and server is disrupted, the next attempt will start with any unchanged files already uploaded.
  3. Added support in the -v switch to have rsync also log to the timebackup log file. This may be handy for cron scripts.
  4. Added the --stats switch with to rsync when being verbose because I'm a numbers geek :smile:
  5. Fixed a small typo in the error text.
  6. When backing up to FreeNAS, the observed behavior of finding files that are 0 days old in the hourly folder would lead to all backups being deleted from the hourly folder. This had the effect of deleting all backups, and thus none would get rotated from the hourly folder.

All changes tested with clients: windows (7, 8.1) with cygwin, ArchLinux. Targeting a FreeNAS server.

Your thoughts, @Mondane ?

Mondane commented 10 years ago

Hi,

Thank you for your changes, they look promising. I'll review them later this week.

Mondane. Op 30 aug. 2014 23:24 schreef "rossica" notifications@github.com:

1.

Added support for unique log files for each backup. The goal is to prevent having one giant log file after a few months of back ups. To correlate any errors experienced with the backup folder that had the error, the log file date and folder date are the same. 2.

The script will now link against any previous incomplete backup. If a back up client has a lot of data to back up and a slow upload speed coupled with unreliable internet connectivity, this will enable the client to complete their back up eventually. Previously, the client would start from scratch every attempt, which means the client needs no (connectivity) issues for the (sometimes long) duration of the backup, in order to successfully back up any data; it's all or nothing. Now, if there is an error, or if the connectivity between client and server is disrupted, the next attempt will start with any unchanged files already uploaded. 3.

Added support in the -v switch to have rsync also log to the timebackup log file. This may be handy for cron scripts. 4.

Added the --stats switch with to rsync when being verbose because I'm a numbers geek [image: :smile:] 5.

Fixed a small typo in the error text. 6.

When backing up to FreeNAS, the observed behavior of finding files that are 0 days old in the hourly folder would lead to all backups being deleted from the hourly folder. This had the effect of deleting all backups, and thus none would get rotated from the hourly folder.

All changes tested with clients: windows (7, 8.1) with cygwin, ArchLinux. Targeting a FreeNAS server.

Your thoughts, @Mondane https://github.com/Mondane ?

You can merge this Pull Request by running

git pull https://github.com/rossica/timebackup rossica

Or view, comment on, or merge it at:

https://github.com/Mondane/timebackup/pull/2 Commit Summary

  • Fix folder deletion logic
  • Link against incomplete transfers, unique log files

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/Mondane/timebackup/pull/2.

Mondane commented 10 years ago

While you're busy, could I ask you to check if the clean-up of extra incomplete folders actually works? It turns out I had hundreds of them in one of my backup locations. It's around line 313 (or 330 in your version).

# Remove any remaining incomplete folders at target, those belong to ghost processes.

It would be much appreciated.

rossica commented 9 years ago

The clean up of incomplete folders has been working for me. I had a lot of incomplete folders from a backup over a flaky connection and they all disappeared when it finally completed.

rossica commented 9 years ago

I just double checked, and the incomplete folders weren't being deleted on my end either. I just committed a change with a fix and now incomplete folders are being deleted.