Limit replication by file age

[Dave Warren]

Is there any way to tell DFS-R to only replicate files that are at least
24 hours old?

The underlying goal is to reduce bandwidth on files that are being
modified on a regular basis, but ensure that all files are replicated
out for redundancy within 24 hours.

My next-best idea is to limit replication to certain hours of the day,
but if more files get changed then can get replicated during that time
period, it may result in files taking many days before being replicated,
which is less then ideal.

I'm pretty sure the answer on this one will be a no, but I thought I'd
ask just in case I missed something.

[HAL07]

Post by Dave Warren
Is there any way to tell DFS-R to only replicate files that are at least
24 hours old?
The underlying goal is to reduce bandwidth on files that are being
modified on a regular basis, but ensure that all files are replicated
out for redundancy within 24 hours.
My next-best idea is to limit replication to certain hours of the day,
but if more files get changed then can get replicated during that time
period, it may result in files taking many days before being replicated,
which is less then ideal.
I'm pretty sure the answer on this one will be a no, but I thought I'd
ask just in case I missed something.

1. Once synced, the DFS will not replicate any files older than 24 hours. DFS algorithm will only try to sync changed files.
2. You should change your DFS schedule. You find it in DFS Management snap-in (
Loading Image...
)
Make sure you have 100% bandwidth allocation outside work-hours.

[DaveMills]

Post by HAL07

Post by Dave Warren
Is there any way to tell DFS-R to only replicate files that are at least
24 hours old?
The underlying goal is to reduce bandwidth on files that are being
modified on a regular basis, but ensure that all files are replicated
out for redundancy within 24 hours.
My next-best idea is to limit replication to certain hours of the day,
but if more files get changed then can get replicated during that time
period, it may result in files taking many days before being replicated,
which is less then ideal.
I'm pretty sure the answer on this one will be a no, but I thought I'd
ask just in case I missed something.

1. Once synced, the DFS will not replicate any files older than 24 hours. DFS algorithm will only try to sync changed files.

Please explain how you deduce this. If this were true then any server offline
for 24 hours will never sync again. That would make DFSR useless.

Post by HAL07
2. You should change your DFS schedule. You find it in DFS Management snap-in (
http://blogs.technet.com/blogfiles/filecab/WindowsLiveWriter/Configuringareadonlyreplicatedfolder_B073/ConfigureReplnSchedule_thumb.png
)
Make sure you have 100% bandwidth allocation outside work-hours.

[Dave Warren]

Post by HAL07

Post by Dave Warren
Is there any way to tell DFS-R to only replicate files that are at least
24 hours old?
The underlying goal is to reduce bandwidth on files that are being
modified on a regular basis, but ensure that all files are replicated
out for redundancy within 24 hours.
My next-best idea is to limit replication to certain hours of the day,
but if more files get changed then can get replicated during that time
period, it may result in files taking many days before being replicated,
which is less then ideal.
I'm pretty sure the answer on this one will be a no, but I thought I'd
ask just in case I missed something.

1. Once synced, the DFS will not replicate any files older than 24 hours. DFS algorithm will only try to sync changed files.

huh? That doesn't make sense. DFS does replicates any changed file
whether it's 2 seconds or 2 weeks old, this is core to it's
functionality.

Post by HAL07
2. You should change your DFS schedule. You find it in DFS Management snap-in (
http://blogs.technet.com/blogfiles/filecab/WindowsLiveWriter/Configuringareadonlyreplicatedfolder_B073/ConfigureReplnSchedule_thumb.png
)
Make sure you have 100% bandwidth allocation outside work-hours.

I can schedule when DFS replicates or limit bandwidth, but that doesn't
really help with what I'm trying to do here.

I'm trying to do is find a replication strategy that will cause DFS-R to
wait a certain amount of time after a file is created/modified before
replicating the file out to partners to avoid wasting bandwidth on
temporary/transient files that are repeatedly modified and/or deleted
minutes after being created.

Files are written 24 hours a day, so preventing all replication at
certain times of day won't really change anything.

As I said in my earlier message, I'm fairly certain that DFS-R can't do
what I'm asking, which is probably why there is some confusion here, but
scheduling by time of day won't help, the only thing that would work
would be if there was some way to delay replication on a per-file basis
for a certain amount of time.

[DaveMills]

If these are true temporary files why replicate them at all, especially is they
will be deleted. You could exclude them from replication by file name pattern.
e.g by default all .tmp files are excluded but you can set your own list, like
*.mytmps"

Post by Dave Warren

Post by HAL07

Post by Dave Warren
Is there any way to tell DFS-R to only replicate files that are at least
24 hours old?
The underlying goal is to reduce bandwidth on files that are being
modified on a regular basis, but ensure that all files are replicated
out for redundancy within 24 hours.
My next-best idea is to limit replication to certain hours of the day,
but if more files get changed then can get replicated during that time
period, it may result in files taking many days before being replicated,
which is less then ideal.
I'm pretty sure the answer on this one will be a no, but I thought I'd
ask just in case I missed something.

1. Once synced, the DFS will not replicate any files older than 24 hours. DFS algorithm will only try to sync changed files.

huh? That doesn't make sense. DFS does replicates any changed file
whether it's 2 seconds or 2 weeks old, this is core to it's
functionality.

Post by HAL07
2. You should change your DFS schedule. You find it in DFS Management snap-in (
http://blogs.technet.com/blogfiles/filecab/WindowsLiveWriter/Configuringareadonlyreplicatedfolder_B073/ConfigureReplnSchedule_thumb.png
)
Make sure you have 100% bandwidth allocation outside work-hours.

I can schedule when DFS replicates or limit bandwidth, but that doesn't
really help with what I'm trying to do here.
I'm trying to do is find a replication strategy that will cause DFS-R to
wait a certain amount of time after a file is created/modified before
replicating the file out to partners to avoid wasting bandwidth on
temporary/transient files that are repeatedly modified and/or deleted
minutes after being created.
Files are written 24 hours a day, so preventing all replication at
certain times of day won't really change anything.
As I said in my earlier message, I'm fairly certain that DFS-R can't do
what I'm asking, which is probably why there is some confusion here, but
scheduling by time of day won't help, the only thing that would work
would be if there was some way to delay replication on a per-file basis
for a certain amount of time.

[Dave Warren]

Post by DaveMills
If these are true temporary files why replicate them at all, especially is they
will be deleted. You could exclude them from replication by file name pattern.
e.g by default all .tmp files are excluded but you can set your own list, like
*.mytmps"

Unfortunately there isn't anything particularly unique about them, I'm
excluding what I can via file name patterns, but it's not a complete
solution.

In some cases it will be an ISO someone ripped while it sits in their
home drive for a few minutes before being copied to it's final
destination or similar.

Even worse is video reencodes which get saved to the network to be
transferred to another user.

The goal was to use DFS-R to give us both local redundancy and a
off-site backup.

I may end up just throttling bandwidth and living with it.