Backup Central

I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories they
are saved in is named by the date/time that the backup was done. At the
moment I use rsnapshot to backup my laptop to a portable hard drive,
usually once a week but sometimes less. Unfortunately, I can't date my
backups so the directory is cluttered with lots of hourly.{0,1,2…}
folders as AFAIK all the other backups simply mirror and relink the
hourly ones. While I can use other tools to look at the creation date of
the directories, it would be much easier if they were named as such.

So for example, instead of hourly.{0,1,2,…}, etc, but YYYY-MM-DD-HHMMSS
and linking it to the previous date in the backup dir. Would this be
practical as an alternative, or would it potentially break too many things?

Robbie

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

On Thu, Jun 21, 2012 at 6:13 AM, Robbie Smith <zoqaeski < at > gmail.com> wrote:
I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories they
are saved in is named by the date/time that the backup was done. At the

It is one of the most requested features. It is consistently rejected
by the maintainers, although I thbink it would be quite useful.

If you're willing to write the perl code to manage, and do the
rotations, and submit it, I bet you'd get a lot further with the
request.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

On Thu, Jun 21, 2012 at 2:44 AM, Nico Kadel-Garcia <nkadel < at > gmail.com> wrote:
On Thu, Jun 21, 2012 at 6:13 AM, Robbie Smith <zoqaeski < at > gmail.com> wrote:
I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories they
are saved in is named by the date/time that the backup was done. At the
It is one of the most requested features. It is consistently rejected
by the maintainers, although I thbink it would be quite useful.

Is there a problem with looking at timestamps?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Hallo, Robbie,

Du meintest am 21.06.12:

I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories
they are saved in is named by the date/time that the backup was done.

That is an old feature request, and the answer from many "rsnapshot"
users is still "no".

You have all informations in the time stamp of the backup directory.

At the moment I use rsnapshot to backup my laptop to a portable hard
drive, usually once a week but sometimes less. Unfortunately, I can't
date my backups so the directory is cluttered with lots of
hourly.{0,1,2?} folders as AFAIK all the other backups simply mirror
and relink the hourly ones. While I can use other tools to look at
the creation date of the directories, it would be much easier if they
were named as such.

Sorry - you can/could tell your file manager to show the time stamp too.
It exists.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Hallo Robbie Smith,

Am Donnerstag, 21. Juni 2012 12:13 schrieb Robbie Smith:
....
ones. While I can use other tools to look at the creation date of
the directories,

What are you using to look at the bakup folders?

it would be much easier if they were named as
such.

You could easily make symlinks with date/time to each backup folder,
but this has to be redone after each backup.

--
Herzliche Grüße!
Rolf Muth
Meine Adressen duerfen nicht fuer Werbung verwendet werden!
PGP Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF8DC41935544C89A
fingerprint: C025 3071 8E56 F8F1 250A 5624 F8DC 4193 5544 C89A

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

On Thu, Jun 21, 2012 at 08:13:24PM +1000, Robbie Smith wrote:

I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories they
are saved in is named by the date/time that the backup was done.

It has been, many times. And has been rejected, many times. The
reasons are:
* that information already exists, in the directory timestamps;
* it would make the code for figurint out which directories to rotate/
rename/delete considerably more complex;
* if you need it, you can write a small shell script to do it with
symlinks

--
David Cantrell | A machine for turning tea into grumpiness

Godliness is next to Englishness

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Am Donnerstag, 21. Juni 2012, 06:44:45 schrieb Nico Kadel-Garcia:
On Thu, Jun 21, 2012 at 6:13 AM, Robbie Smith <zoqaeski < at > gmail.com> wrote:
I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories they
are saved in is named by the date/time that the backup was done. At the

It is one of the most requested features. It is consistently rejected
by the maintainers, although I thbink it would be quite useful.

I do not need the feature, but I can see one major use case. "Traditional"
backup programs used on rsnapshot trees like constant directory names as it is
difficult to tell them that daily.0 has moved to daily.1 and does not need a
new backup.


If you're willing to write the perl code to manage, and do the
rotations, and submit it, I bet you'd get a lot further with the
request.

I'm not good enough as a programmer to even try integration into existing
code, but the algorithm isn't complex. Date calculations or state keeping is
not required. It might be even less lines of code than today.

Accepting a minor drawback and using a smart naming scheme, the gist of the
algorithm stays the same. Just exchange file names for array indexes.

Naming scheme: <level><year><month><day><hour><minute>, e. g.
daily-2012-06-21-18-40

1) grep daily* and sort the array
2) "Rotation": Delete oldest (array[0]) and create new directory
3) Promotion: Rename oldest lower level (daily-2012... -> weekly-2012...)

The only drawback I can see is that promotions still cause the same effects as
the current code.

Eliminating this and the level prefix does not even require state keeping or
calculating with dates: The first x (see parsed variable from rsnapshot.conf)
dates/directories in an unfiltered array as above are daily, the next y are
weekly etc.

Hopefully this encourages someone to do the real work.

Johannes Niess

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

The algorithm exists in my ezrsnapshots bash program (which I probably should just make a page for) and nothing rotates or promotes anywhwere. I would say the code(which exists, but not in perl) is probably not much more complicated because there are no rotation steps needed. It's possible that I could eliminate that without using time stamped file names, but once you're processing times and making permanent file names anyway it really doesn't matter. The real point of my script though wasn't to change the names.. just a nice bonus, and the fact that the code maybe isn't much more complicated comes from a broader reinvention than just this feature alone, which by itself does add complication for little gain.
There's a strong point raised that I very much get, that mucking with a stable and an established code and user behavior for something like this causes hesitation for good reason. It's easy to play with ideas in alpha code when nobody is using it yet.


BTRFS (a COW snapshotting filesystem) has an fsck now, so all of this stuff might be silly soon anyway.

dagurasu


From: email < at > johannes-niess.de
To: rsnapshot-discuss < at > lists.sourceforge.net
Date: Thu, 21 Jun 2012 19:49:20 +0200
Subject: Re: [rsnapshot-discuss] Feature Request: timestamping backups

Am Donnerstag, 21. Juni 2012, 06:44:45 schrieb Nico Kadel-Garcia:
On Thu, Jun 21, 2012 at 6:13 AM, Robbie Smith <zoqaeski < at > gmail.com> wrote:
I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories they
are saved in is named by the date/time that the backup was done. At the

It is one of the most requested features. It is consistently rejected
by the maintainers, although I thbink it would be quite useful.

I do not need the feature, but I can see one major use case. "Traditional"
backup programs used on rsnapshot trees like constant directory names as it is
difficult to tell them that daily.0 has moved to daily.1 and does not need a
new backup.


If you're willing to write the perl code to manage, and do the
rotations, and submit it, I bet you'd get a lot further with the
request.

I'm not good enough as a programmer to even try integration into existing
code, but the algorithm isn't complex. Date calculations or state keeping is
not required. It might be even less lines of code than today.

Accepting a minor drawback and using a smart naming scheme, the gist of the
algorithm stays the same. Just exchange file names for array indexes.

Naming scheme: <level><year><month><day><hour><minute>, e. g.
daily-2012-06-21-18-40

1) grep daily* and sort the array
2) "Rotation": Delete oldest (array[0]) and create new directory
3) Promotion: Rename oldest lower level (daily-2012... -> weekly-2012...)

The only drawback I can see is that promotions still cause the same effects as
the current code.

Eliminating this and the level prefix does not even require state keeping or
calculating with dates: The first x (see parsed variable from rsnapshot.conf)
dates/directories in an unfiltered array as above are daily, the next y are
weekly etc.

Hopefully this encourages someone to do the real work.

Johannes Niess

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

I'll also add, in defense of the developers, that this is backup software. Changing ANYTHING about its default behavior may cause someone who relied on that behavior to have unintended side effects which could have huge measurable costs. This isn't an mp3 player program. Tinkering for every amusing feature idea is probably not desirable.

dagurasu.


From: dagurasu-forge < at > hotmail.com
To: email < at > johannes-niess.de; rsnapshot-discuss < at > lists.sourceforge.net
Date: Mon, 25 Jun 2012 03:37:12 +0000
Subject: Re: [rsnapshot-discuss] Feature Request: timestamping backups



The algorithm exists in my ezrsnapshots bash program (which I probably should just make a page for) and nothing rotates or promotes anywhwere. I would say the code(which exists, but not in perl) is probably not much more complicated because there are no rotation steps needed. It's possible that I could eliminate that without using time stamped file names, but once you're processing times and making permanent file names anyway it really doesn't matter. The real point of my script though wasn't to change the names.. just a nice bonus, and the fact that the code maybe isn't much more complicated comes from a broader reinvention than just this feature alone, which by itself does add complication for little gain.
There's a strong point raised that I very much get, that mucking with a stable and an established code and user behavior for something like this causes hesitation for good reason. It's easy to play with ideas in alpha code when nobody is using it yet.


BTRFS (a COW snapshotting filesystem) has an fsck now, so all of this stuff might be silly soon anyway.

dagurasu


From: email < at > johannes-niess.de
To: rsnapshot-discuss < at > lists.sourceforge.net
Date: Thu, 21 Jun 2012 19:49:20 +0200
Subject: Re: [rsnapshot-discuss] Feature Request: timestamping backups

Am Donnerstag, 21. Juni 2012, 06:44:45 schrieb Nico Kadel-Garcia:
On Thu, Jun 21, 2012 at 6:13 AM, Robbie Smith <zoqaeski < at > gmail.com> wrote:
I don't know if this has been brought up before, but a useful feature
would be the ability to configure backups so that the directories they
are saved in is named by the date/time that the backup was done. At the

It is one of the most requested features. It is consistently rejected
by the maintainers, although I thbink it would be quite useful.

I do not need the feature, but I can see one major use case. "Traditional"
backup programs used on rsnapshot trees like constant directory names as it is
difficult to tell them that daily.0 has moved to daily.1 and does not need a
new backup.


If you're willing to write the perl code to manage, and do the
rotations, and submit it, I bet you'd get a lot further with the
request.

I'm not good enough as a programmer to even try integration into existing
code, but the algorithm isn't complex. Date calculations or state keeping is
not required. It might be even less lines of code than today.

Accepting a minor drawback and using a smart naming scheme, the gist of the
algorithm stays the same. Just exchange file names for array indexes.

Naming scheme: <level><year><month><day><hour><minute>, e. g.
daily-2012-06-21-18-40

1) grep daily* and sort the array
2) "Rotation": Delete oldest (array[0]) and create new directory
3) Promotion: Rename oldest lower level (daily-2012... -> weekly-2012...)

The only drawback I can see is that promotions still cause the same effects as
the current code.

Eliminating this and the level prefix does not even require state keeping or
calculating with dates: The first x (see parsed variable from rsnapshot.conf)
dates/directories in an unfiltered array as above are daily, the next y are
weekly etc.

Hopefully this encourages someone to do the real work.

Johannes Niess

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss





------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ rsnapshot-discuss mailing list rsnapshot-discuss < at > lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

On Sun, Jun 24, 2012 at 7:37 PM, Dagurasu Dagurasu
<dagurasu-forge < at > hotmail.com> wrote:

The algorithm exists in my ezrsnapshots bash program (which I probably
should just make a page for)

That would be nice.

There's a strong point raised that I very much get, that mucking with a
stable and an established code and user behavior for something like this
causes hesitation for good reason.  It's easy to play with ideas in alpha
code when nobody is using it yet.

But we should also ask ourselves if it's even a good idea to even
place in alpha code.
The time and date does exist. It's in the time stamp. That's been
said over and over and over.

Creating more code to solve a problem that doesn't exist isn't a good thing.

BTRFS (a COW snapshotting filesystem) has an fsck now, so all of this stuff
might be silly soon anyway.

It's also still not ready as a production filesystem used for backups, IMO.
(and also that of the developer, Tso.)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Hallo, Dagurasu,

Du meintest am 25.06.12:

BTRFS (a COW snapshotting filesystem) has an fsck now, so all of this
stuff might be silly soon anyway.

But it's not very helpful - sorry.
I've worked with BTRFS for many months. It's not reliable, yet. And that
means you shouldn't use it for backups, especially for backups with
"rsnapshot".

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

The algorithm exists in my ezrsnapshots bash program (which I probably
should just make a page for)

That would be nice.

There's a strong point raised that I very much get, that mucking with a
stable and an established code and user behavior for something like this
causes hesitation for good reason. It's easy to play with ideas in alpha
code when nobody is using it yet.

But we should also ask ourselves if it's even a good idea to even
place in alpha code.
The time and date does exist. It's in the time stamp. That's been
said over and over and over.


yes but it makes sense in the context of a code that keeps fixed file names anyway, which just happens to be extremely useful for simplifying everything else.


Creating more code to solve a problem that doesn't exist isn't a good thing.


I agree as far as filenaming for its own sake. ls -tral does the same thing.


dagurasu



BTRFS (a COW snapshotting filesystem) has an fsck now, so all of this stuff
might be silly soon anyway.

It's also still not ready as a production filesystem used for backups, IMO.
(and also that of the developer, Tso.)



I also agree, which is why I said soon maybe. The fsck seemed rushed out to list one point.


From: kenwoods < at > ken-woods.com
Date: Sun, 24 Jun 2012 20:17:51 -0800
Subject: Re: [rsnapshot-discuss] Feature Request: timestamping backups
To: dagurasu-forge < at > hotmail.com
CC: email < at > johannes-niess.de; rsnapshot-discuss < at > lists.sourceforge.net

On Sun, Jun 24, 2012 at 7:37 PM, Dagurasu Dagurasu
<dagurasu-forge < at > hotmail.com> wrote:

The algorithm exists in my ezrsnapshots bash program (which I probably
should just make a page for)

That would be nice.

There's a strong point raised that I very much get, that mucking with a
stable and an established code and user behavior for something like this
causes hesitation for good reason. It's easy to play with ideas in alpha
code when nobody is using it yet.

But we should also ask ourselves if it's even a good idea to even
place in alpha code.
The time and date does exist. It's in the time stamp. That's been
said over and over and over.

Creating more code to solve a problem that doesn't exist isn't a good thing.

BTRFS (a COW snapshotting filesystem) has an fsck now, so all of this stuff
might be silly soon anyway.

It's also still not ready as a production filesystem used for backups, IMO.
(and also that of the developer, Tso.)

The point is not backups with rsnapshot, the point is it's a naturally self-snapshotting filesystem if it works and you don't need rsnapshot. I understand that it's not there yet. Backups and snapshots are not entirely the same problem either. Snapshotting with the live fs itself for instance is not a backup solution. Backing up to a snapshoting fs could be though at some point.

-dagurasu.



Date: Mon, 25 Jun 2012 06:36:00 +0200
From: Hullen < at > t-online.de
To: rsnapshot-discuss < at > lists.sourceforge.net
Subject: Re: [rsnapshot-discuss] Feature Request: timestamping backups

Hallo, Dagurasu,

Du meintest am 25.06.12:

BTRFS (a COW snapshotting filesystem) has an fsck now, so all of this
stuff might be silly soon anyway.

But it's not very helpful - sorry.
I've worked with BTRFS for many months. It's not reliable, yet. And that
means you shouldn't use it for backups, especially for backups with
"rsnapshot".

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Hallo, Dagurasu,

Du meintest am 25.06.12:

[BTRFS]

The point is not backups with rsnapshot, the point is it's a
naturally self-snapshotting filesystem if it works and you don't
need rsnapshot. I understand that it's not there yet. Backups and
snapshots are not entirely the same problem either. Snapshotting
with the live fs itself for instance is not a backup solution.
Backing up to a snapshoting fs could be though at some point.

It's a very good idea to put the backups on another disk than the "real"
data.

The btrfs snapshots are no reliable backup.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

unless you periodically backup to a btrfs filesystem and snapshot the backup!

Sorry I didn't mean to go this far on a tangent with this, but anyway, that's the notion. It was just an afterthought.


-dagurasu


Date: Mon, 25 Jun 2012 07:15:00 +0200
From: Hullen < at > t-online.de
To: rsnapshot-discuss < at > lists.sourceforge.net
Subject: Re: [rsnapshot-discuss] Feature Request: timestamping backups

Hallo, Dagurasu,

Du meintest am 25.06.12:

[BTRFS]

The point is not backups with rsnapshot, the point is it's a
naturally self-snapshotting filesystem if it works and you don't
need rsnapshot. I understand that it's not there yet. Backups and
snapshots are not entirely the same problem either. Snapshotting
with the live fs itself for instance is not a backup solution.
Backing up to a snapshoting fs could be though at some point.

It's a very good idea to put the backups on another disk than the "real"
data.

The btrfs snapshots are no reliable backup.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss