[rdiff-backup-users] Mozy Online Back-Up Problems
I installed MOZY FREE Backup software on my computer by following their instructions. After installation, my computer kept freezing and then I got the Windows Blue Screen of Death! Basically, MOZY FREE Backup CRASHED my computer. I could not even do a system restore. I had to restore my computer from scratch. I am still in the process of putting back all my programs and files, this is very time consuming. Furthermore, after I backed up my files, I could not retrieve them using another computer. It kept telling me that I had to register and install MOZY Backup, it just would not retrieve my previous registration. I am still not able to retrieve my files. Luckily, I kept local backups on some DVD's. MOZY may be free, but there is always a catch. Please be aware Mozy free backup could crash your computer? Maybe that's how they get you; then they tell you have to purchase one of their plans??? FYI: I have 2GB of RAM and a 2.0 GHz AMD processor and it still CRASHED it! +-- |This was sent by jlri...@gmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Mozy Online Back-Up Problems
On Mon, Aug 24, 2009 at 05:11:46PM -0400, infomax467 wrote: Basically, MOZY FREE Backup CRASHED my computer. [...] Maybe that's how they get you; then they tell you have to purchase one of their plans??? FYI: I have 2GB of RAM and a 2.0 GHz AMD processor and it still CRASHED it! It's most likely the software stressed your system to the point that an existing problem was revealed. (Probably either a driver bug or an actual hardware problem.) The conspiracy you suggest seems like it'd be bad business -- who would trust such a company? rdiff-backup can put similar stress on a system, and it's likely we can find a similar story if we look hard enough. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] unable to recover from interrupted backup
Ben Tucker wrote: I had a machine fail in the midst of backing up a couple weeks ago and ever since I have been unable to get it to successfully backup. rdiff-backup --check-destination-dir runs without error, but then running the actual backup command results in an exception. I'm running 1.2.8 stock deb install on Ubuntu jaunty. The client machine is also running 1.2.8 (also ubuntu). These are the only versions of rdiff-backup with have been used. I'd greatly appreciate any pointers on how to resolve this. Thanks! Did you get this sorted? It sounds an alarming problem for any of us who have important repositories of data going back over a long period; the whole thing could get trashed by one failed backup! I give below a way (posted here by Steven a few weeks ago, all credit to him) to force a regression. This might undo the 'bad' backup(s) that you have and then allow you to make further backups. I haven't had the need to try it but it might help you: Dominic While rdiff-backup is making a backup it creates a new current_mirror.$timestamp.data file in the rdiff-backup-data destination directory. Once it's done making the backup, it deletes the old current_mirror file. In other words, while the backup is running there are two current_mirror files. In order to undo a backup, you'll need to to create a fake current_mirror file with the timestamp of the previous backup and run rdiff-backup -v6 --check-destination-dir $dest. rdiff-backup will be fooled into thinking the latest backup failed and revert it. I do not know of a way to regress more than one backup at once, but this method should work multiple times. P.S. A full example in case my description isn't clear: $ mkdir source $ echo 1 source/a $ echo 2 source/b $ rdiff-backup source dest $ ls dest a b rdiff-backup-data $ rm source/a $ rdiff-backup source dest $ ls dest b rdiff-backup-data $ ls dest/rdiff-backup-data/mirror* dest/rdiff-backup-data/mirror_metadata.2009-07-03T18:47:33-06:00.diff.gz dest/rdiff-backup-data/mirror_metadata.2009-07-03T18:48:12-06:00.snapshot.gz $ echo PID 99 \ dest/rdiff-backup-data/current_mirror.2009-07-03T18:47:33-06:00.diff.gz $ rdiff-backup -v6 --check-destination-dir dest Using rdiff-backup version 1.2.7 ... snip ... Regressing to Fri Jul 3 18:47:33 2009 ... snip ... Regressing file a ... snip ... Cleaning up $ ls dest a b rdiff-backup-data ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] A bug in rdiff-backup with changing files
Josh Nisly wrote: One of my clients encountered an interesting bug in rdiff-backup - under certain conditions, if a file changes while it is being backed up, rdiff-backup throws an unhandled exception... I can't help on the main problem, but as a workaround (and a better approach anyway), users should backup from a snapshot - or, in Windows terminology, a 'Volume Shadow'. This is the approach I take in my TimeDicer script. That way files can't change or be locked during a backup. (Note that it might still be possible for files to be in an inconsistent state, though if the application manipulating them is 'volume shadow aware', they shouldn't be.) Dominic ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
[rdiff-backup-users] Bad index order
Hi!
I'm new to rdiff-backup. I'm using it under Windows (Vista). The first
time I tried to backup my harddrive it gives me an error, which possibly
originates from special characters I like to use. Please have a look:
Exception 'Bad index order: ('Pictures', '2006', '20060326-0401
T\xfcrkei', '032
9 G\xfcnes Tutulmasi in Aspendos', 'p3292216.jpg') = ('Pictures',
'2006', '2006
0326-0401 T\xfcrkei', '0329 G\xfcnes Tutulmasi in Aspendos')' raised of
class '
type 'exceptions.AssertionError'':
File rdiff_backup\Main.pyc, line 304, in error_check_Main
File rdiff_backup\Main.pyc, line 324, in Main
File rdiff_backup\Main.pyc, line 280, in take_action
File rdiff_backup\Main.pyc, line 346, in Backup
File rdiff_backup\backup.pyc, line 38, in Mirror
File rdiff_backup\backup.pyc, line 232, in patch
File rdiff_backup\rorpiter.pyc, line 275, in __call__
Traceback (most recent call last):
File rdiff-backup, line 30, in module
File rdiff_backup\Main.pyc, line 304, in error_check_Main
File rdiff_backup\Main.pyc, line 324, in Main
File rdiff_backup\Main.pyc, line 280, in take_action
File rdiff_backup\Main.pyc, line 346, in Backup
File rdiff_backup\backup.pyc, line 38, in Mirror
File rdiff_backup\backup.pyc, line 232, in patch
File rdiff_backup\rorpiter.pyc, line 275, in __call__
AssertionError: Bad index order: ('Pictures', '2006', '20060326-0401
T\xfcrkei',
'0329 G\xfcnes Tutulmasi in Aspendos', 'p3292216.jpg') = ('Pictures',
'2006',
'20060326-0401 T\xfcrkei', '0329 G\xfcnes Tutulmasi in Aspendos')
Can someone fix that? Is it really because of the character I'm using in
the directory name?
The folder path is:
C:\Users\admin\Pictures\2006\20060326-0401 Türkei\0329 Günes Tutulmasi
in Aspendos
Would be very nice if that could be fixed.
Thanks and best regards -
- Daniel
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
[rdiff-backup-users] Quick question - Can rdiff (or anything else) do this?
I have some large files, such as hard drive images for virtual machines, which will change a few blocks at a time but most of the file remains unchanged, and I would like to backup efficiently. Needless to say it is bad to send the whole file across every time. I would like a diff-like program which will analyze the file in chunks, and only send across the chunks which changed from last time. This would gain little or no performance boost if copying from disk-to-disk, but when there is a WAN in between the source and destination, it could greatly improve the transfer time. Can rdiff (or anything that anyone knows of) do this? Thank you. ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Quick question - Can rdiff (or anything else) do this?
On Tue, Aug 25, 2009 at 17:17, Edward Harveyedward.har...@lyricsemiconductor.com wrote: Can rdiff (or anything that anyone knows of) do this? storebackup can http://www.nongnu.org/storebackup/ ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] A bug in rdiff-backup with changing files
Josh Nisly wrote: One of my clients encountered an interesting bug in rdiff-backup - under certain conditions, if a file changes while it is being backed up, rdiff-backup throws an unhandled exception... I can't help on the main problem, but as a workaround (and a better approach anyway), users should backup from a snapshot - or, in Windows terminology, a 'Volume Shadow'. This is the approach I take in my TimeDicer script. That way files can't change or be locked during a backup. (Note that it might still be possible for files to be in an inconsistent state, though if the application manipulating them is 'volume shadow aware', they shouldn't be.) Dominic ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] unable to recover from interrupted backup
Ben Tucker wrote: I had a machine fail in the midst of backing up a couple weeks ago and ever since I have been unable to get it to successfully backup. rdiff-backup --check-destination-dir runs without error, but then running the actual backup command results in an exception. I'm running 1.2.8 stock deb install on Ubuntu jaunty. The client machine is also running 1.2.8 (also ubuntu). These are the only versions of rdiff-backup with have been used. I'd greatly appreciate any pointers on how to resolve this. Thanks! Did you get this sorted? It sounds an alarming problem for any of us who have important repositories of data going back over a long period; the whole thing could get trashed by one failed backup! I give below a way (posted here by Steven a few weeks ago) to force a regression. This might undo the 'bad' backup(s) that you have and then allow you to make further backups. I haven't had the need to try it but it might help you: Dominic While rdiff-backup is making a backup it creates a new current_mirror.$timestamp.data file in the rdiff-backup-data destination directory. Once it's done making the backup, it deletes the old current_mirror file. In other words, while the backup is running there are two current_mirror files. In order to undo a backup, you'll need to to create a fake current_mirror file with the timestamp of the previous backup and run rdiff-backup -v6 --check-destination-dir $dest. rdiff-backup will be fooled into thinking the latest backup failed and revert it. I do not know of a way to regress more than one backup at once, but this method should work multiple times. P.S. A full example in case my description isn't clear: $ mkdir source $ echo 1 source/a $ echo 2 source/b $ rdiff-backup source dest $ ls dest a b rdiff-backup-data $ rm source/a $ rdiff-backup source dest $ ls dest b rdiff-backup-data $ ls dest/rdiff-backup-data/mirror* dest/rdiff-backup-data/mirror_metadata.2009-07-03T18:47:33-06:00.diff.gz dest/rdiff-backup-data/mirror_metadata.2009-07-03T18:48:12-06:00.snapshot.gz $ echo PID 99 \ dest/rdiff-backup-data/current_mirror.2009-07-03T18:47:33-06:00.diff.gz $ rdiff-backup -v6 --check-destination-dir dest Using rdiff-backup version 1.2.7 ... snip ... Regressing to Fri Jul 3 18:47:33 2009 ... snip ... Regressing file a ... snip ... Cleaning up $ ls dest a b rdiff-backup-data ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
