mintBackup Fork

[exploder]

Will it back up the entire system?

[clem]

Hi Ikey,

It's shaping up nicely.

Clem.

[exploder]

ikey, you are one talented individual! That is brilliant work!

[hemimaniac]

Looks pretty good so far m8, keep up the good work!

[Roin]

IMHO a good backup tool is what Mint misses and yours looks exactly like a good backup tool ikey. Keep it up m8.
Afterall the old Mintbackup was... well lets say incomplete and caused me some headaches in #linuxmint-help when somebody asked me how to use it to extract the .backup files again (espacily in Mint 5-7 when you couldnt just launch the Mint tools from the command line xD).
I'm so excited about seeing your Mintbackup in Mint 9 ^_^ .

Greets,
Roin

[XidCat]

Ikey... Really appreciate you picking this up. I'm tired of messing about with rsync. Because Mint is not a rolling release, a good backup will make upgrading virtually painless. Heck, the way I screw stuff up, it's necessary all the time Your screens are awesome, just what the doctor ordered. Thanks again...

[piratesmack]

Nice tool, ikey

What about xz as a compression option?
It's about 15% smaller than bzip2 and decompresses faster too.

[tenfoot]

Hi Ikey

Greetings from your friendly geriatric in New Zealand Very interested in your project. Will it be released with Isadora?

[jarviser]

Keep an eye on this tutorial for updates,

Ikey, greetings from the UK, under a cloud of volcanic ash...
I took version 2.0.1 of mintbackup from that site. It looks OK, gives me all the new choices that were not in v1.5 but when I try to backup /home to a usb 2.5" drive it seems to try and write a few files then bombs, no error messages. Just writes a few folders in .cache and writes a .mintbackup file that says
source: /media/80GBFreecom
destination: /home/peter
file_count: 30473
description: mintBackup
but it only writes about 80 of the 30473 files (more than 30GB of media etc). I even formatted the drive ext3 to give it a bit of help when the original FAT version failed. Any ideas or is that a very immature version of the tool?

If I'm busting in on the wrong thread I'll post it again in the right place. Peter.

[jarviser]

OK will do. Looking forward for what is probably the world's first incremental backup tool in Linux.

And the only way I found to add a folder to Places in the tool was to go into exclude folders, add to the Places tree, then go back to the beginning - Is that correct?

If you could include in any documentation, which folders in Filesystem to clean-up for a clean install of a new mintbackup version it would help. J.

[El_Tate]

Hey, actually there's a tool which does incrementally backups. And it's called Deja Dup, it's based on duplicity and seems to be quite complete.
I don't want to be rude, and i like the new tool in fact. But, maybe we can get some features of Deja Dup into the new backup tool.

Also the option to have tar.xz compressed files would be nice, since its faster than bz2 and do a better job IMO. And with xz also 7z and zip can be included (but without file permissions since they don't work on LSB or Posix systems by what i know). Also DAR can be used since can compress and archive.

Cheers.

[jarviser]

I took version 2.0.1 of mintbackup from that site. It looks OK, gives me all the new choices that were not in v1.5 but when I try to backup /home to a usb 2.5" drive it seems to try and write a few files then bombs, no error messages......

Ikey I downloaded V2.02 of the tool and this time no problems. Wrote all 31000 files in my home folder except 6 gvfs related files which were errored.

Out of interest I backed up about 30GB of which 18GB is music files. The initial backup took just under 3 hours and (observing the larger files) I would say the bulk of the time was taken up with checksum calculation. I thought I had requested modify time as advanced option so I was surprised it calculated checksums.

I ran a subsequent backup, having added 1 file, with default checksum as the overwrite criterion and it was successfully was ignoring identical files. However it was taking almost as long to run as the original write so I stopped it and tried again with file size as the overwrite criterion. This took under a minute to find and write the new file to the backup. That is a nice bit of incremental backing up! I'll just have to hope changed files are not the same size but that is a low probability.

Next test was to try another incremental backup using modify time as overwrite criterion and again it started calculating checksums and taking forever so I stopped it. So I guess I'm asking is the modify time option coded fully?

A nice-to-have would be for the tool to remember the overwrite criteria in an ini file if it has one so it could just run next time without having to change advanced options each time.

[El_Tate]

Yes, that's right i'm the same guy who posted on the blog...

Yes, i did know that XZ and LZMA are closely related, but thanks for point out that. Okay 7z isn't good for backups (but can be used with tar to preserve file permissions), but can you tell me the (main) difference between zip and gzip please?, cuz zlib uses the same algorithm as katz's zip (or info-zip which also supports file permissions in posix file systems and ntfs).

I'm wondered why for you zip it's an ugly format, since gzip is based on it. I mean, zip, gzip, info-zip, dotnetzip, libzip or almost any based zip library uses deflate as main algorithm, only 7z and XZ uses LZMA (and 7z has his own implementation of Deflate wich seems to perform better than zlib), the diference is, of course, that zip isn't a solid compressor (which 7z and tgz/tbz2/txz are). That's why i suggested the inclusion of 7z and XZ, since both uses the same thing and the 1st can archive.

Also, maybe you can help me with a small project that i've to do for the univ, if you want of course. I've to do a module (in asp.net unfortunally) to make backups, and i've to choice a good lib to compress the files (in volumes too). Originally i thought the use of zlib, 7za or DotNetZip, but maybe you can point me the right way. It has to be used inside the program. And i can use tar to archive also (in case that only choose a non-archiver compressor)

And... some non-native formats sometimes perform better than the native ones, i don't see the big deal with that since we are choosing between free/libre alternatives. I mean... i don't request to use rar as main format to store the data or uha or whatever... :p

I don't want to be misunderstood, i mean... i use mint, i promote mint, i like mint (and his tools), and i just want to try to propose ideas which i think that we can benefit of all of us, since i'm tired to choose between a lot of alternatives and each one does a "something" that the other don't. We need to unite the things up in order to came with better choices for the newcomers and simplify things for the "old" users.

Thanks and you're welcome.

[El_Tate]

Thanks for answer (Y).

I was asking for a stand-alone lib and the i'll code the methods to compress, in java i know that are some implementations but differ from .net (which, again, i don't like it at all and i can't use mono with xsp for the assigature)

Cheers

[jarviser]

You'll see the "Calculating Checksums" on both the overwrite (Checksum mistmatch) option
and on "Check integrity". It will calculate the SHA-256 hash for both files and compare them,
which may take some time. I may have to add command line switches for those needing more control..

Switches would be good.
I would expect the tool (v 2.0.2) to compare checksums if the default checksum option was selected. But I would expect the 'Filesize mismatch' and the 'Modify Time Mismatch' options to compare checksums only where there was a difference in size or time (or indeed a new file instance) when comparing the source and the backup.
So when I tested the filesize overwrite option and found it checks integrity only of the modified file it found, that was what I expected.
However when testing the Modify Time overwrite option, I found it calculates checksums on all files in the home folder before recognizing the date/times are the same. I would expect it to check the date/times before checking integrity.
From a purely layman's point of view, both size and date/time are simple file properties which should take roughly the same amount of time to read, and I would have expected similar behaviour for both options, even if check integrity is on.

[feed3]

hi ikey..
just for the sake of info, after doing this;

Upgraded the following packages:
mintbackup (1.6.4) to 2.0.3

am getting an error complaining of cant configuring mintbackup whenever i install new apps, its constantly complaining that it cant update desktop-database. resolved by installing desktop-file-utils. i'm using mint helena kde 32bit with kde 4.4.2 by the way.
i dont know if it is because of my upgraded kde or something else. just in case if someone else getting the same errors.

if the issues is already being discussed somewhere else, just let me know and i will delete this post.

and many thanks for the great tool ikey! pretty sure it will help me a lot in the near future..

[jarviser]

Upgraded to 2.0.3 on Gnome based Mint 8 - no such problems as feed3 got.
Follow-up incremental backup on the 30GB file set now only took 5 minutes using Modify Time, even with integrity checks.