Shirt Pocket Discussions

Shirt Pocket Discussions (http://www.shirt-pocket.com/forums/index.php)
-   General (http://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Incremental Backup (http://www.shirt-pocket.com/forums/showthread.php?t=262)

Axxll 03-15-2005 01:49 AM

Incremental Backup
 
For the time being, I use smart backup from my Powerbook to mmy external Maxtor HD. I am not clear tho on the following scenario:

Suppose i have downloaded something ( say a movie) then after io watched it i wanted to archive it onto my Maxtor, using smart backup would copy whats on my HD .

then, suppose i deleted my file ( the movie) from my HD and did another smart backup. Does SP delete files that are not on HD( the movie file) but are on Maxtor in order to maintain and exact image of my HD.?

In other words: does smart backup provide for incremental backup.? if not then how to do it.?

thanks

dnanian 03-15-2005 08:48 AM

Yes, Smart Update deletes files that are on the backup but aren't on the source by definition. (Copy Newer and Copy Different do not.)

Check out the description of these different copy modes in the User's Guide -- I go into considerable detail about what they do and how they work: you may find that other "During copy" choices will meet your needs in other situations, too!

Axxll 03-15-2005 02:02 PM

Incremental Backup
 
I went thru the userguide. I am not sure about the difference between copy diffferent and copy new.

which one gives me incremental backup.?

i.e: exact image of my source HD but does not delete what was on my destination HD from previous backup .

thanks

dnanian 03-15-2005 03:11 PM

Smart Update is what you should use. That produces an exact copy of the source quickly, by only making the necessary changes.

Axxll 03-16-2005 12:03 AM

Quote:

Originally Posted by dnanian
Smart Update is what you should use. That produces an exact copy of the source quickly, by only making the necessary changes.

But you said smartupdate will delete files on destination that are not on source anymore !!. I dont want to lose files on destination becausse i had to delete them on source.!!

Furthermore., at one time i tried both backups. (new) and (different) after 2 or 3 backsups my destination HD became full ( 250GB) while my source was only 80 GB .it appeared to me that SDuper was duplicating something. i hhad to erase destination and start all over again. :confused:

dnanian 03-16-2005 08:41 AM

OK, sorry: your request was worded vaguely, as you indicated you wanted an exact clone. You cannot have an exact copy if you leave files on the destination that are no longer on the source.

Note that if you don't have an exact clone, we can't guarantee that the result will be bootable. Some updates actually remove or move files from one location to another, and leaving the 'old' versions on the disk could prevent it from booting or running properly. (Of course, it's still a good backup of the various files, it's just not a bootable one.)

If you want to copy any changes -- including newly created files -- from the source to the destination, without deleting any files on it, use "Copy Different". If you only want to copy files that are newer -- meaning newly created or with newer change dates -- use "Copy Newer".

I can't give an answer to the other issue without a bit more information. Please send a copy of your SuperDuper!.log (it's off your Home folder in Library/Logs) as well as a brief description of the problem to support. (Don't post it here.) I'll take a look and see if I can tell what happened.

slboettcher 03-18-2005 01:38 PM

Axxll:

If your external hard drive is a larger capacity than your PowerBook, you should do this:
I have the same setup, and I partitioned my external hard drive in two partitions - one is the same size as the PowerBook (60GB) and the other is 20GB. I use the second partition to store those "extra" files and keep the main partition for the PowerBook clone.

HTH,
SB

Axxll 03-19-2005 02:39 AM

I did just that SB thanks. However i had to use Deja Vu for the archive partiion whereby Deja Vu allows me to choser which folder to backup. and i kept my Clone partion for smart backup of my PB.

thank you all anyway for your help :D

edh 06-28-2005 12:38 PM

I want to use smart backup via a network. Everything's seems dandy, I get the backup I want. The first backup was a complete backup, which took about six hours (for 60G), which I find acceptable given it had to go via a cable connection.
However, I immediately started a new back up and expected smart backup to go much quicker. But after 5.5 hours it still has not finished. Any thoughts?
Eduard.

dnanian 06-28-2005 12:48 PM

Not yet -- wait for it to finish (if it does) and let's see what the log says it copied. That'll give a better idea of what's going on.

edh 06-29-2005 12:54 AM

smart copy via network seems to copy too much
 
First backup took six hours, smart update after that took almost as long.

The relevant parts in the log (http://snowcrash.ai.ru.nl/superduper.log)

In the first run
|12:49:31 PM|Info| Scanned 1207441 items occupying 49.63 GB (172844 directories, 1021801 files, 12796 symlinks)
|12:49:31 PM|Info| Copied 13747 items totaling 46.39 GB (346 directories, 932 files, 12469 symlinks)
|12:49:31 PM|Info| Cloned 46.39 GB of data in 22165 seconds at an effective transfer rate of 2.14 MB/s

In the second run (smart backup)
|06:45:59 PM|Info| Scanned 1207729 items occupying 49.65 GB (172903 directories, 1022028 files, 12798 symlinks)
|06:45:59 PM|Info| Copied 13717 items totaling 46.40 GB (301 directories, 945 files, 12471 symlinks)
|06:45:59 PM|Info| Cloned 46.40 GB of data in 20487 seconds at an effective transfer rate of 2.32 MB/s

dnanian 06-29-2005 07:33 AM

Well, it looks like your link is awfully, awfully slow. We're not copying the data -- but traversing the source and destination drives and just comparing is what's taking the time.

(You can see that we're only copying 900 items or so...)

So, Smart Update is doing what it's supposed to do... but the network is too slow for it to really help.

Is this on a LAN or a WAN?

edh 06-29-2005 02:07 PM

Quote:

Originally Posted by dnanian
Well, it looks like your link is awfully, awfully slow.
...
So, Smart Update is doing what it's supposed to do... but the network is too slow for it to really help.
...
Is this on a LAN or a WAN?

1. I take it "Copied 13717 items totaling 46.40 GB" in the log means what it says, namely 46+GB copied.
2. also "effective transfer rate of 2.32 MB/s" for 6 hours is about 50G, so that data seems actually transfered, or else I don't understand the 'effective' TR.
I don't believe 2.3Mbs transfer as awfully slow. On campus we have a 1Gps network, but I am not sure about the cable to home in tandem. I think it is relatively fast.
3. My major worry is that the complete backup and smart backup take about equally long (via WAN). And that the log seems to say that there was about 45 G transfered, both during complete backup, and then during smart backup. Eduard.
PS we can take this off-line as I don't see others with this problem.

dnanian 06-29-2005 02:19 PM

The stat is misleading -- all of the files evaluated totaled 46.40GB. The actual transfer was much smaller -- only 900ish files. (I don't know how large they were.)

In fact, in both cases, it only copied about that number of files, out of a much larger number: were you copying on top of an existing backup?

edh 06-30-2005 03:28 AM

smart update via WAN not yet resolved
 
[QUOTE=dnanian]The stat is misleading ...

Sorry to drag this on for so long, apparently unable to explain my point. Let's see.
1. I made a complete backup, starting with a new i.e. empty sparseimage. That took six hours. I understand that and I don't mind, as there are about 50G to copy via a cable connection.
2. Then I made a smart update on top of this backup. It took about the same time as the previous complete backup.
3. I think this could only have happened if the majority of files, and especially the big ones, had changed status.

When I do a local smart update (HD on firewire) it goes a lot quicker, as expected.
I know the cable's speed is asymmetric, high speed down and low speed up. But I am doing the backup in the direction of high speed (work->home).

I will try another smart update via the network and see what happens. No really big files should have changed since last time.

Ediard

dnanian 06-30-2005 07:31 AM

I really do understand what you're saying. But, given what I'm seeing in the log, it looks like the same files were copied for both runs, and in each case you provided only 900 files were copied out of the total.

I can't tell how large they were, but the total size of all files examined was 50G.

Regardless of the size of the files, we're still going to be traversing the entire directory structure. This might be doing enough I/O across your very slow link that it's going to make the whole backup go slowly. (You can't really think of it as up/down, because we can't really tell what the OS is going to do when traversing/statting the various files, sparse image, etc.)

To compare them more exactly I'd need to see the entire log, not just two little snippets from what look to be nearly identical partial runs, neither of which was a full copy. You can send that to support, if you'd like, after you do the next smart update.

edh 07-01-2005 03:17 AM

I started a new smart backup right after the previous one finished (which was after six hours). The new backup took even longer; eight hours. Between these backups there were no big files that had changed status, which I checked with find / -ctime -540 (ie. using a nine hours interval). The files that had changed were predominantly /Network files (for about 500 machines). There is not enough in the log to fare on, especially as you mention, its figures seem to be misleading. I'm mystified. Eduard.

dnanian 07-01-2005 07:03 AM

The count isn't misleading, only the total size...

I don't know, Eduard. Have you tried the backup to a local drive to see if it's fast?


All times are GMT -4. The time now is 09:12 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.